Not So Frequently Asked Questions

Intentes connectar-te via remote desktop (terminal server) al servidor, però et trobes que ja hi ha gent connectada. El maleït missatge:

Què fer en aquest cas? Doncs molt senzill. Donat que tenim la nostra flamant eina winexe , podem fer un petit script que ens faciliti la vida:

#!/bin/bash

[ ! -z "$2" ] && [ $2 != disc ] && echo "Error: Can't understand second argument" && echo "Use: $0 server [disc #session]" && exit
[ "$2" == "disc" ] && echo "Disconnecting session $3 from server $1..." && winexe //$1 "logoff $3" -A secretfile && exit
echo "Listing server $1 sessions:"
winexe //$1 "query session" -A secretfile


L’arxiu “secretfile” és opcional, és per no haver de posar usuari i contrassenya. El seu contingut és aquest:

domain=YOURDOMAIN
username=user
password=pass


Es un script sense gaire control d’errors, pero et permet veure qui hi ha connectat:

[email protected]:~/$ ts.sh server2
Listing server server2 sessions:
SESSIONNAME USERNAME ID STATE TYPE DEVICE
> user1 0 Disc rdpwd
rdp-tcp 65536 Listen rdpwd
Administrator 3 Disc rdpwd
user2 1 Disc rdpwd
console 5 Conn wdcon
[email protected]:~/$


En aquest servidor ja no s’hi pot entrar. Veiem que tothom esta en estat “disconnected”, amb la qual cosa no hi ha ningú treballant. Escollim l’usuari que ens caigui pitjor, i el fem fora:

[email protected]:~/$ ts.sh server2 disc 1
Disconnecting session 1 from server server2...
[email protected]:~/$ ts.sh server2
Listing server server2 sessions:
SESSIONNAME USERNAME ID STATE TYPE DEVICE
> user1 0 Disc rdpwd
rdp-tcp 65536 Listen rdpwd
Administrator 3 Disc rdpwd
console 5 Conn wdcon


Et voilà! ja tenim una sessió lliure per connectar-nos a administrar aquest servidor.

Evidentment és molt millor que tothom tanqui el terminal server quan acabi de treballar. Però si has de compartir servidors amb despistats, t’has de buscar la vida…

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 (