Primer exemple d’execució remota de pstools: winps.sh

La següent missió era fer scripts que executessin les diferents pstools remotament. Vaig començar fent-ne un per cada, pero vaig trobar que tots compartien molta part de codi, així que vaig decidir crear un script generic, psexec.sh (en “honor” al psexec de les pstools), al que li poguessim passar el nom del servidor i la eina que voliem executar, amb els seus parametres. I després l’unic que ens quedaria seria crear un wrapper per cada comanda que ens fes la feina mes còmoda.

El script ha de comprovar si les credencials del fitxer són bones, i demanar-ne d’altres si no ho són. Un cop autenticat, ha de comprovar si existeixen les pstools o no, i copiar-les en cas que no.

En la historia completa podreu veure el codi del psexec.sh i d’un wrapper d’exemple, el winps.sh. Recordeu que per funcionar, necessiten dels fitxers winvars.sh i cp_pstools.sh, que apareixien en rc=$?

if [ $rc -eq 0 ];then
echo "Default credentials"
elif [ $rc -eq 1 ];then
echo "$? Hola"
echo "Default credentials doesn't authentify. Try others."
read -p "Type username (DOMAIN/user):" user
read -s -p "Type password:" pass
PSCREDENTIALS="--user $user --password $pass"
winexe //$1 "$TOOLS_UNIT:\$TOOLS_DIR\pstools\pslist.exe /accepteula -t" $PSCREDENTIALS
rc=$?
if [ $rc -eq 1 ];then
echo "Credentials error or unit not available (check smbmount errors)" && exit 1
elif [ $rc -eq 99 ];then
echo "There's no pstools, I'll copy them"
$PROGPATH/cp_pstools.sh $1 $user $pass
[ $? -ne 0 ] && echo "There's no pstools and I couldn't copy them." && exit 1
winexe //$1 "d:\scripts\pstools\pslist.exe /accepteula -t" $PSCREDENTIALS
rc=$?
if [ $rc -eq 99 ];then
echo "Pstools are copied, but they don'y work, somethings going on." && exit 1
fi
fi
elif [ $rc -eq 99 ];then
echo "There's no pstools, I'll copy them"
$PROGPATH/cp_pstools.sh $1
[ $? -ne 0 ] && echo "There's no pstools and I couldn't copy them." && exit 1
winexe //$1 "d:\scripts\pstools\pslist.exe /accepteula -t" $PSCREDENTIALS
rc=$?
if [ $rc -eq 99 ];then
echo "Pstools are copied, but they don'y work, somethings going on." && exit 1
fi
fi

Exemple de wrapper: winps.sh

#!/bin/bash

[ $# -ne 1 ] && echo "Error, I need one and only one argument" && exit 1
PROGPATH=echo $0 | /bin/sed -e 's,[\/][^\/][^\/]*$,,'
$PROGPATH/psexec.sh $1 pstools\pslist -t

Copiant automàticament les pstools al servidor windows des del teu linux

En la línia en la que anàvem… Què passa si volem fer servir les pstools en 50 servidors? Una idea és crear una unitat compartida i que tots les executin des d’allà. Pero si tenim alguns en unes xarxes, unes en unes altres (fins i tot en DMZ), amb dominis i sense… No podria haver alguna forma còmoda de copiar-los?

Doncs per aquest motiu he creat aquest petit script, que fa exactament això: copiar les pstools al servidor que volguem. Primer munta la unitat cifs (amb smbmount), després copia els fitxers i després la desmunta.

Està pensat per ser cridat des d’altres scripts. Per exemple, si fem un “winps”, primer que comprovi si estan les pstools instal·lades, i si no ho estan, que les copii. Per això, posarem un fitxer de variables que puguin fer servir tots els scripts, de forma que si volem canviar algun parametre no haguem de modificar-los tots. A aquest fitxer li direm “winvars.sh”.

En l’article complet podeu mirar el codi i descarregar el fitxer.

winvars.sh

#!/bin/bash

TOOLS_DIR=tools
TOOLS_UNIT=d
CREDENTIALS="/home/user/secretfile"
SMBCREDENTIALS="credentials=$CREDENTIALS"
PSCREDENTIALS="-A $CREDENTIALS"

La diferència entre les SMBCREDENTIALS i les PSCREDENTIALS està en la forma d’acceptar-les que té el smbmount i el winexe.

cp_pstools.sh

#!/bin/bash

# We get the script path
PROGPATH=echo $0 | /bin/sed -e 's,[\/][^\/][^\/]*$,,'
# We load our vars
. $PROGPATH/winvars.sh

PSTOOLS_SRC=/home/user/pstools/
RAND_DIR=$1-$RANDOM

[ $# -lt 1 ] && echo "Error, too few parameters" && echo "Use: $0 server [unit]" && exit
[ ! -z "$2" ] && SMBCREDENTIALS="username=$2,password=$3"

mkdir /tmp/$RAND_DIR
smbmount //$1/$TOOLS_UNIT$ /tmp/$RAND_DIR -o $SMBCREDENTIALS

if [ $? -eq 0 ];then
echo "Default credentials"
else
echo "Default credentials doesn't authentify. Try others."
read -p "Type username (DOMAIN/user):" user
read -s -p "Type password:" pass
smbmount //$1/$TOOLS_UNIT$ /tmp/$RAND_DIR -o username=$user,password=$pass
[ $? -ne 0 ] && echo "Credentials error or unit not available (check smbmount errors)" && rmdir /tmp/$RAND_DIR && exit 1
fi

mkdir /tmp/$RAND_DIR/$TOOLS_DIR
cp -av $PSTOOLS_SRC /tmp/$RAND_DIR/$TOOLS_DIR/.
smbumount /tmp/$RAND_DIR

rmdir /tmp/$RAND_DIR

Desconnectant usuaris de l’escriptori remot (terminal server) de windows

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

You can't connect!

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

[ $# -lt 1 ] && echo "Error: Missing argument" && echo "Use: $0 server [disc #session]" && exit

[ ! -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…

La meva màquina se’m reinicia quan no pot veure els discos SAN!

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.

SAMBA i caràcters especials (accents, ñ…)

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!