oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: storage

Avoid Filling Your System with Docker Logs: A Quick Guide

Reading time: 2 – 3 minutes

If you’re using Docker, you might have noticed that over time, logs can accumulate and take up a significant amount of space on your system. This can be a concern, especially if you’re running containers that generate a lot of log data.

To help you avoid this issue, I’m sharing a quick configuration tweak for Docker. By adjusting the daemon.json file, you can limit the size and number of log files Docker retains.

Here’s the configuration:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "1"
  }
}

What does this configuration do?

  • "log-driver": "json-file": This ensures Docker uses the default json-file logging driver, which writes log messages in JSON format.
  • "log-opts": {...}: This section contains the logging options.
    • "max-size": "10m": Limits the maximum size of each log file to 10MB.
    • "max-file": "1": Restricts Docker to retain only one log file.

By implementing this configuration, you ensure that Docker only keeps a single log file with a maximum size of 10MB. Once the log reaches this size, Docker will rotate it, ensuring that old logs don’t eat up your storage.

To apply this configuration, simply add the above JSON to your daemon.json file, typically located at /etc/docker/daemon.json on Linux systems. After making the change, restart the Docker service.

I hope this tip helps you manage your Docker logs more efficiently. Happy containerizing! 🐳

QNAP TS-439 Pro II – Servidor NAS

Reading time: 2 – 3 minutes

Després de que aquest mes d’agost caigués un llamp a casa del veï he hagut de canviar forces coses que tenia per casa, una d’elles és el servidor de NAS que tenia fins ara, es tractava d’un HP ML110 G4 que amb 6 discs durs i amb el software appliance d’OpenFiler m’havia fet una molt bona feina els últims temps, però entre els problemes de hardware deguts al llamp i que fa molt de temps que OpenFiler no s’actualitza, al final m’he decidit a comprar un QNAP TS-439 Pro II TurboNAS. De moment he de dir que no podia haver fet millor compra, malgrat no hi ha res perfecte en aquest món he de dir que tot i ser un producte força car les seva infinitat de funcionalitats i simplicitat d’ús ja m’han estalviat més calers dels que val. Per cert, suposo que no cal dir que té un cor Linux, oi?
TS-439ProII
Per donar fer de la gran quanitat de funcionalitats que té en destacaré unes quantes, ja aviso que no les diré totes perquè això faria que això fos un post inmens.

  • file server (SAMBA)
  • FTP server
  • printer server
  • web server
  • Windows AD support
  • WebDAV
  • Share Folder Aggregation (also known as DFS)
  • IPv6 and IPv4 dual-stack
  • Wake on LAN
  • schedule power on/ off
  • HDD S.M.A.R.T
  • comprehensive log systems
  • policy-based unauthorized IP blocking
  • VMWare vSphere4 (ESX 4.0 and above) certified
  • iSCSI
  • multiple LUNs management
  • Secure IP SAN (CHAP auth and ACL)
  • SPC-3 clustered environment
  • MPIO for failover and load balancing
  • VDD (Virtual Disk Drive)
  • Encrypted remote replication
  • Backup button and complete backup solution
  • RAID 0,1,5,5+hot spare, 6 and JBOD
  • Dual LAN: failover, load balancing and multi-IP setting
  • Alerts via SMS and email
  • SNMP
  • Shared folder agregation
  • QPKG: Joola, mldonkey, asterisk, etc.
  • NTFS, FAT32, EXT3, EXT4
  • SMB, AFP, NFS
  • ISO mount
  • UPnP and DLNA server
  • Web Multimedia center, really powerful
  • DDNS
  • Hot-SWAP
  • etc

Malgrat sembli que la llista és llarguíssima, com deia abans m’estic deixant de posar moltíssimes coses, així doncs, ús el recomano moltíssim.

Eines de recuperació de dades

Reading time: 1 – 2 minutes

A través del blog d’en Xavier Caballé trobo un article amb un recull d’eines de recuperació de dades. Després de contrastar-ho amb el Manel i amb la seva experiència a Inforescate la llista s’ha ampliat i queda així:

  • TestDisk, per a Windows, Mac i Linux
  • Recuva, per a Windows
  • PhotoRec, per a Windows, Mac i Linux
  • Restoration, per a Windows
  • Undelete Plus, per a Windows
  • Captain Nemo
  • Get Data Back for FAT
  • Get Data Back for NTFS
  • UFS Explorer
  • Active Partition Recovery
  • R-Studio
  • Stellar Phoenix
  • Raid Reconstructor
  • Data Doctor Recovery for Removable Media
  • Directory OPUS (explorador de fitxers SUPREM!)

openfiler: potent i complicat de configurar

Reading time: 4 – 6 minutes

M’ha costat deu i ajuda posar a funcionar l’openfiler al final ja era una qüestió d’honor. Després de provar amb la versió pre-instal·lada com appliance i amb dues versions instal·lades per mi no hi havia manera de que funcionés tot plegat com volia.

Problema reconeixer volums lògics pre-creats

El primer gran problema ha estat que jo ja tenia un volume group creat, amb dos logic volumes (unitats lògiques d’informació usades per LVM). Doncs bé malgrat el linux me’ls retornava sense problemes amb el vgdisplay i lvdisplay quan anava a l’interficie de l’openfiler no hi havia manera que apareguessin els volums lògics. El grup de volums si que sortia però els lògics no. Doncs bé la solució l’he trobat després de molt buscar pels forums a aquest thread: How to get volumes back after reinstallation without config backup.

La gràcia esta en un script que bàsicament genera un fitxer XML de configuració que usa l’openfiler per saber quins volums hi ha al sistema: /opt/openfiler/etc/volumes.xml. El fitxer és força simple i només té una llista de volums lògics relacionats a un grup de volums. L’script també afegeix al /etc/fstab les línies necessaries perquè aquests volums lògics es montin a l’arrancar el sistema.

Còpia de l’script que he trobat al forum: remake_vol_info.

Problema LDAP amb tots els serveis i especialment amb el SMB

Doncs bé, aprofitant que openfiler porta un servidor LDAP volia gestionar les comptes de tots els serveis a través d’un únic punt. Així doncs, el primer problema ha estat saber com activar el servidor que porta internament perquè la documentació no ho explica massa bé, ja que si anem a serveis i li fem un enable sense donar cap error no s’aixeca ni a la de tres. Aprofito per comentar que la interficie gràfica de l’openfiler és realment pèssima i difícil d’entendre. A més, l’experiència d’usuari esta molt poc cuidada perquè moltes coses donen errors i no ho explica retorna enlloc. Així doncs t’hs de buscar la vida monitoritzant els fitxers de logs del linux que té per darrera.

Llavors he intentat actualitzar el sistema a través de la funció d’update que porta la pròpia interficie. Doncs be, també fallava així doncs ho he provat des de la línia de comandes amb un simple:

conary updateall

La cosa fallava amb el mateix error:

...
Warning: Unhandled exception occured when invoking callback
/user/lib/pgthon2.4/site-packages/conary/streams.py:416
...

Després de googlejar una bona estona, la solució ha estat:

conary update conary --replace-files
conary updateall --replace-files

Amb això he aconseguit finalment fer update. Però el problema amb LDAP continuava igual. Al final he deduit que si posava la informació a accounts -> authentication. Amb el password que he posat al fer la instal·lació per l’usuari de configuració del web la part d’usuaris i grups semblava que s’activa i el LDAP server començava a funcionar tot solet.

ldap.png

Així doncs, he pogut accedir a la gestió de comptes i crear un grup d’usuaris i un usuari de proves. Doncs bé, després de suar tinta per entendre tot el tema de gestió de shares i de veure que no hi havia manera d’accedir als recursos compartits de forma autenticada, he decidit aprofitar la meva experiència en linux per veure com estava tot configurat.

La qüestió és que he vist que tan el SMB, com el FTP, HTTP/WebDav, etc. anaben contra PAM però aquest no tenia configurat cap enllaç cap a LDAP, per tant, per molt que estigués funcionant era impossible que mai autentiques cap usuari.

Llavors he executat el authconfig per configurar l’autenticació PAM contra LDAP, i l’he deixat així:

Al marcar l’autenticació LDAP per SMB, no ús ho perdeu m’ha dit que faltava el paquet pam_smb, o sigui, el pàquet de PAM que té el handler capaç de gestionar la connexió contra LDAP pel samba. Algú em pot explicar com pretenien la gent d’openfiler autenticar samba amb LDAP si no hi havia això instal·lat? aquí ja he arribat a la conclusió que això de l’openfiler esta verdíssim.

Bé doncs, després de suar una mica amb tot això que comento ja funciona tot contra LDAP a la perfecció!!! realment he de reconeixer que sóc una persona obstinada,eh!? perquè n’hi ha per deixar-ho correr. Després de tot el que he explicat i les hores que he hagut d’invertir per descobrir-ho.

Rendiment OpenFiler virtual

Reading time: 2 – 2 minutes

Porto tot el dia fent proves amb l’OpenFiler com a màquina virtual dins del servidor HP que estic montant. Doncs, bé apart dels detalls tècnics volia fer una simple i interessant prova que després de veure el resultat encara em té estorat. He fet un test de velocitat amb el hdparm per saber la velocitat de transferència entre l’ubuntu que fa de servidor d’VMWare i un disc dur de 750Gb:

root@vm0:~# hdparm -t /dev/sdc1
/dev/sdc1:
 Timing buffered disk reads:  314 MB in  3.02 seconds = 104.11 MB/sec

Després des de la màquina virtual amb OpenFiler (basat en linux Red Hat) he fet la màteixa prova:

[root@nas0 ~]# hdparm -t /dev/sdb1
/dev/sdb1:
 Timing buffered disk reads:   66 MB in  3.05 seconds =  21.65 MB/sec

Malgrat el nom del dispositiu surti diferent el dispositiu és el mateix, això passa perquè en la màquina virtual el dispositiu no és el tercer dispositiu ‘SATA‘, sinó el segon. La màquina virtual té capturat el dispositiu físic, així doncs trobo que la diferència de velocitat és exagerada. També s’ha de comentar que l’OpenFiler no m’ha deixat instal·lar-se en 64bits sobre VMWare i ho he hagut de fer amb 32bits, no sé pas si aquesta diferència tan brutal pot ser deguda a això.

Els recursos que tinc assignats a l’OpenFiler són:

nas0.png

Si algú té la possibilitat de fer alguna prova semblant, o l’ha fet que avisi. De totes formes, diria que amb màquines virtuals de 64bits no puc capturar el dispositiu real o això m’ha semblat llegir que deia el VMWare. Gran defecte sota el meu punt de vista.

AoE – ATA over Ethernet

Reading time: 2 – 2 minutes

Més d’una vegada ho havia sentit. Però mai m’havia plantejat perquè carai podia servir això. De fet, el tema és ben senzill SAN. O sigui, que podem agafar el nostre ordinador sense disc dur (diskless) i botar-lo a través de PXE, però encomptes de montar-nos un RAMDISK per treballar amb el sistema, el que podem fer és usar un disc dur connectat al nostre sistema a través de la xarxa.

Així doncs, no tenim problemes d’espai, ni de treballar amb memòria volàtil. Com a molt els podem tenir de velocitat, per tal d’evitar això és una bona idea usar força caché de disc a la RAM del sistema. De fet, tot consultant el tema als forums de gentoo he vist que molta gents fins hi tot tira les X’s amb gestors de finestres sense problemes, tot i que quan parlem de GNOMEs i KDEs la cosa es complica una mica.

Malgrat pugui semblar un invent d’anar per casa, al mercat podem trobar diversos productes que implementen aquest estàndard. De fet, fins hi tot Intel té processadors i plaques base especialment dissenyades per treballar amb aquest protocol.

Quan parlem de AoE molta gent tendeix a confondre Ethernet amb TCP/IP. Ja sabreu una cosa no té res que veure amb l’altre. Amb això vull matitzar que el AoE va directament sobre la capa 2 i que no és un protocol enrutable. Amb això aconsegueix aprofitar al màxim l’amplada de banda del cable Ethernet i a més podem switchejar la senyal. Per si necessiteu un equivalent del AoE però que funcioni sobre IP i que per tant sigui enrutable, penseu amb el iCSI.

aoe-iscsi-comparison.gif