Not So Frequently Asked Questions

Tens els teu servidors Linux, amb un Oracle 10g RAC. Tot funciona fantàsticament, però de sobte una màquina es reinicia. Mires els logs i et trobes això:

Sep 18 00:27:24 server1 kernel: SCSI error : <2 0 2 0> return code = 0x20000
Sep 18 00:27:24 server1 kernel: end_request: I/O error, dev sdae, sector 1672
Sep 18 00:27:24 server1 kernel: device-mapper: dm-multipath: Failing path 65:224.
Sep 18 00:34:14 server1 syslogd 1.4.1: restart.
Sep 18 00:34:14 server1 syslog: syslogd startup succeeded
Sep 18 00:34:14 server1 kernel: klogd 1.4.1, log source = /proc/kmsg started.


D’acord… han fallat els discos SAN… la màquina ha perdut part dels discos… Pero això no sembla motiu suficient com per reiniciar-se, no? L’arrel del sistema operatiu (la “/”) està muntada sobre un disc local. De fet sobre els discos de la SAN només hi ha l’ocfs de l’Oracle… El que seria normal és que hagués caigut l’Oracle i ja està, no? Per què s’ha reiniciat la màquina completa?

Doncs resulta que antigament, Oracle RAC, quan es trobava en aquesta situació, intentava treure la màquina del cluster fent un “evict node”. Pero això no funcionava, el driver ocfs2 es quedava penjat, moltes vegades deixant penjat el cluster complet (totes les màquines del cluster). Solució dràstica… Quina és la forma més segura de sortir d’un cluster? Doncs reiniciant la maquina. Pimpampum.

També podrien haver fet que l’Oracle deixés algun missatge de log avisant-te que ha estat ell qui ho reiniciava, i així les coses haguessin estat mes clares. Però no es pot tenir tot.

Així que si et trobes que la teva màquina es reinicia quan perd l’accés a la SAN, no culpis la màquina i no culpis l’Oracle… fes que arreglin la SAN perquè no torni a passar.

Normalment no s’acostuma a posar caràcters estranys als noms dels fitxers, per evitar problemes. Però això no significa que no es pugui fer, i que ho haguem d’evitar. De fet, programes com el Word fan servir la primera línia del document (el títol) per suggerir un nom per defecte a l’usuari, amb la qual cosa si el títol portava algun accent, el nom del fitxer també el tindrà…

Desafortunadament, SAMBA no sembla estar configurat per defecte per mostrar correctament aquests fitxers, i els substitueix per un underscore (guió baix, “_”), amb la qual cosa hem de tocar la configuració de la següent manera:

SAMBA com a client: és a dir, quan vols accedir des del teu linux a una unitat remota.

Antigament, quan es feia servir el driver SMB per fer el mount, s’havia de posar la opció “nls=utf8”:

mount -t smb //REMOTE/shared /mnt/remote/shared -o credentials=FILE,nls=utf8

Ara, el driver CIFS (que substitueix el SMB perquè està completament obsolet) ja està preparat i no cal:

mount -t cifs //REMOTE/shared /mnt/remote/shared -o credentials=FILE

Ara pots fer tranquilament un touch /mnt/remote/shared/tomàs_núñez.txt i el fitxer es crearà sense problemes.

SAMBA com a servidor: és a dir, quan volem compartir els documents del nostre linux amb altres equips
En aquest cas hem d’afegir dues opcions al fitxer de configuració smb.conf (normalment /etc/samba/smb.conf):

dos charset = 850
unix charset = ISO8859-15


D’aquesta manera ja estaran compartits els fitxers amb accents i ñ i tot!

M’he trobat que executant les pstools directament des de consola, sense entorn gràfic (en el meu cas, fent servir winexe ), es quedava aturat, com penjat. Fent la prova, i connectant-me via remote desktop al servidor, i executant-les a mà, apareix una finestreta amb una EULA (llicencia d’ús) que s’ha d’acceptar. És a dir, que només s’ha de fer click en “Ok, I agree”.

Si això et passa en un sol servidor no hi ha cap problema, però si tenies planejat executar les pstools en més de 50 servidors, és inviable anar un per un executant alguna de les eines per poder acceptar la EULA.

A l’ajuda de les eines, i a la documentació oficial no apareix cap manera de poder passar per sobre d’això. Però a una web (que ara mateix he perdut, m’encantaria tenir-la per poder donar-li el crèdit) he trobat un paràmetre que no estava publicat: /accepteula

Només haurem d’afegir aquest paràmetre als nostres scripts perquè no ens torni a donar problemes l’acceptació de la llicència. Exemple:

winexe -U HOME/Administrator%Pass123 //host "d:scriptspstoolspslist.exe /accepteula"


Així podrem fer un ps de qualsevol servidor sense haver-nos de preocupar de si és la primera vegada que fem servir el pslist o no.

En el post anterior en el que parlàvem del winexe, explicàvem com executar comandes del shell de windows mitjançant la nostra consola linux. La intenció original era engegar i aturar serveis ( net start; net stop), però un cop tenim el shell a windows podem anar més enllà i fer moltes més coses. Per això podem fer servir les pstools .

Amb elles podrem sentir-nos com si estiguéssim a la nostra consola de windows, perquè podrem tenir el ps (pslist, un kill (