Quins processos consumeixen més SWAP en un linux?
Tan senzill com llençar un top i un cop dins l’interficie premer O (majúscula) i seguidament p, amb un intro tornem a la pantalla del top i apareix una nova columna anomenada SWAP que ens diu quantes pàgines de memòria consumeix un procés, a més la llista de processos que es poden veure estan ordenats per ordre descendent segons el que més memòria SWAP ocupa.
Aprofitant l’article adjunto una referència interessant: Controlling your linux processes via linux.com.
Autenticació PAM/OTP via PHP
Una bona forma de continuar aprofindint amb el tema OTP i també amb PAM, després de l’article: Shellinabox i OTP, és explicar-vos com m’ho he fet per afegir suport OTP al PHP, de forma que quan programem amb PHP es pugui delegar l’autenticació al sistema PAM del linux. Obviament això té certes restriccions perquè PHP corre amb els permisos de l’usuari de l’Apache, o bé, de l’usuari del FSGI, etc. L’important de fer notar és que no és habitual llençar codi PHP amb permisos de ‘root’. Així doncs, depèn de quina acció li fem fer al PAM aquest no la podrà dur a terme, per exemple, no podrà accedir al fitxer /etc/shadow per validar el password de sistema. De fet, com que el que jo vull és treballar amb OTP això no és rellevant.
El primer que s’ha de fer és instal·lar el paquet php5-auth-apm i reiniciar l’Apache:
apt-get install php5-auth-pam
/etc/init.d/apache2 restart
Ara anem al directori /etc/pam-script.d i fem:
cd /etc/pam-script.d
rm pam_script_acct
# creem fitxer pam_script_acct
echo '#!/bin/sh' > pam_script_acct
echo 'exit 0' >> pam_script_acct
chmod 755 pam_script_acct
Ara toca crear el fitxer /etc/pam.d/php, amb el següent contingut:
auth sufficient pam_script.so onerr=fail dir=/etc/pam-script.d/
account required pam_script.so onerr=fail dir=/etc/pam-script.d/
Amb això ja en tenim prou per anar a jugar amb el php, el primer és amb un phpinfo(); validar que apareix algo així:
i després podem fer un codi tan senzill com aquest:
<?php
$result=pam_auth('user','password-otp',&$error);
var_dump($result);
var_dump($error);
?>
La comanda clau com podeu veure és pam_auth, passeu com a paràmetre el nom de l’usuari, el password que ús ha donat la vostre aplicació generadora de passwords OTP i la variable que voleu que reculli els errors la passeu per referencia. En cas d’error de l’autenticació aquesta comanda contindrà la descripció de l’error. Aquesta mateixa funció retorna un codi boleà amb el resultat de l’autenticació.
Shellinabox i OTP (One Time Password)
A vegades cal poder accedir a la shell d’un servidor però no es disposa de cap client SSH ni res semblant, o fins hi tot hi ha casos en que només si pot accedir a través de proxy usant HTTP, ni tan sols es disposa d’HTTPs. Per aquests casos el que he fet és montar el següent:
Un shellinabox que és un dimoni que publica una shell a través d’HTTP, de forma que es pot usar el navegador com a client. A diferència d’altres solucions aquesta esta implementada aprofitant AJAX i no li cal suport de flash, java o d’altres tecnologies similars. Si no l’heu provat, feu-ho perquè és impressionant el bé que arriba a funcionar.
Bé doncs, gràcies al dimoni de shellinabox ja podriem publicar al port 80 la pantalla de login del nostre servidor, però en el meu cas al port 80 hi tinc l’Apache funcionant, així doncs, el que he fet és montar un proxy invers aprofitant les funcionalitats d’Apache, de forma que quan em connecto a un subdomini concret l’Apache redirecciona la meva connexió HTTP al servidor de shellinabox.
Al usar aquest client que funciona sobre un protocol sense xifrar tothom podria aconseguir de forma senzilla l’usuari i password que uso per accedir a la shell. Per tal de solucionar aquest problema el que he fet és instal·lar com a mètode d’autenticació al PAM del servidor suport OTP.
O sigui, que quan l’usuari fa login per qualsevol servei que usi el sistema d’autenticació ‘common-auth’ del PAM aquest podrà fer-ho amb el password del sistema o bé amb un password d’un sol ús. Això em garanteix que després de que jo m’hagi autenticat a la shell amb un password ningú més ho podrà fer amb aquell password.
Esquema de la idea
Configuració d’apache, proxy invers
Primer de tot cal activar el modul ‘proxy’ de l’Apache:
a2enmod proxy
Després creem un subdomini i re-enviem el tràfic cap al servidor de shellinabox:
<VirtualHost *:80>
ServerName elteusubdomini.exmaple.tld
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:4200/
ProxyPassReverse / http://127.0.0.1:4200/
LogFormat "%h %l %u %t \"%r\" %>s %B \"%{Referer}i\" \"%{User-Agent}i\" %D" common
CustomLog /var/log/apache2/elteusubdomini.exmaple.tld.access.log common
ErrorLog /var/log/apache2/elteusubdomini.exmaple.tld.error.log
LogLevel warn
</VirtualHost>
Després d’això ja podeu reiniciar l’apache, recordeu a crear la corresponent entrada al DNS.
Paràmetres que uso pel shellinabox
Malgrat el manual del shellinabox esta plè d’opcions molt interessants en el meu cas amb els següents paràmetres n’he tingut prou:
/opt/shellinabox/bin/shellinaboxd --no-beep -t -b
- –no-beep no vull que emeti ‘beeps’, proveu-ho sense això a mi em van fotre un ensurt que encara tremolo
- -t per deshabilitar l’SSL que s’activa per defecte
- -b es llença en background
Configuració d’OTP al PAM del linux
El suport OTP que he afegit al PAM és molt limitat i bàsic, ja que no volia afegir més complexitat al sistema, o sigui, que per controlar els usuaris que poden accedir via OTP he usat un simple fitxer de text pla i per validar l’autenticació em recolzo amb el pam_script que és un mòdul de PAM que permet llençar un script arbitrari per validar l’autenticació.
Potser una de les formes més recomanables si voleu usar OTP en un servidor més professional que el que jo he usat seria fer-ho a través de RADIUS, o bé, usant MOAS el qual ofereix una interficie web feta amb PHP i backend MySQL per mantenir una taula d’usuaris i d’altres detalls de configuració.
Tornant al cas que ens ocupa, la configuració de PAM que he usat és tan senzilla com:
# fitxer: /etc/pam.d/common-auth
...
auth sufficient pam_script.so onerr=fail dir=/etc/pam-script.d/
auth sufficient pam_unix.so nullok_secure try_first_pass
...
La primera línia afegeix suport de pam_script per l’autenticació, a més de posar-hi dos paràmetres que indiquen que si aquesta falla fallarà l’autenticació i també indica a quin directori s’ha d’anar a buscar l’script d’autenticació. Aquí és on es provarà si s’ha introduït un password OTP.
La segona línia és estàndard en l’ubuntu on he fet la configuració, excepte l’últim paràmetre try_first_pass que diu que torni a provar el password que s’ha introduït en el pas anterior, així no l’hem de re-introduïr per validar si el password intruït és un password de sistema.
Ambdues línies usen la ‘flag’ sufficient, o sigui que si algún dambdós es compleix serà suficient per validar positivament l’autenticació.
El pam_script és un mòdul de PAM que al instal·lar-lo ens ha creat la carpeta /etc/pam-script.d amb uns quants fitxers al seu interior. Aquí l’únic que haurem de fer és borrar l’enllaç simbòlic anomenat: /etc/pam-script.d/pam_script_auth. Ja que per defecte aquest apunta a /etc/pam-script.d/pam_script i nosaltres no volem usar l’script per defecte sinó el nostre propi script, o sigui, el que fa la validació OTP.
L’script que fa la validació l’he modificat una miqueta respecte l’script per defecte i l’he col·locat a: /opt/otp/otp-auth. Ara ja podem refer l’enllaç simbòlic que haviem borrat abans:
ln -s /etc/pam-script.d/pam_script_auth /opt/otp/otp-auth
En el directori /opt/otp/ cal que tinguem també:
- otp-auth – script que fa la validació, fet amb Perl i amb alguna dependència
- otp-secrets – fitxer de configuració dels usuaris que poden usar OTP
- cache/ – directori necessari per guardar-hi claus de forma temporal
El fitxer de configuració del /opt/otp/otp-auth el /opt/otp/otp-secrets té aquest pinta:
%users =
(
username =>
{
secret => 'codi_secret_compartit_amb_eina_client',
pin => ping_acces_eina_client,
offset => 0,
},
anotheruser =>
{
secret => 'ZZZZZZZZZZZZZZZZ',
pin => IIII,
offset => 0,
},
);
1;
En el meu cas, el secret l’he generat amb l’eina client que m’he instal·lat al mòbil (Android). El pin simplement ús el podeu inventar i és necessari introduir-lo al client que genera les claus.
Client OTP per Android
El client que he usat per Android és el Mobile-OTP, quan l’executeu per primera vegada ús guiarà perquè genereu un secret i un pin quan els tingueu els heu de posar al fitxer de configuració /opt/otp/otp-secrets.
Procés d’ús
Anem a un navegador qualsevol connectat a internet, accedim al subdomini que hem definit i ens surt una pantalla de login, introduïm l’usuari i ens demana el password.
Ara agafem el mòbil i obrim l’aplicació Mobile-OTP, posem el codi PIN i premem el botó ‘Calculate OTP’ inmediatament després ens surt un codi amb números i lletres i una longitud de 6 caràcters, introduïm aquest codi com a password de la nostre compte i ja som dins.
Recordeu que aquest codi és vàlid durant uns 2 minuts aproximadament, després l’haureu de tornar a generar. Aquest codi també deixa de ser vàlid en el moment en que ja l’heu usat un cop, o sigui, que si voleu fer dos logins seguits haureu de generar dos codis.
També es pot usar OTP amb altres serveis
Recordeu que al configurar el sistema d’autenticació OTP al PAM ho he fet a l’arxiu ‘common-auth’, això vol dir que qualsevol servei de la màquina que usi aquest fitxer d’autenticació (la majoria ho fan: SSH, POP3, IMAP, etc) suportarà el sistema d’autenticació OTP.
Així doncs, si feu un SSH dels de tota la vida cap a la vostre màquina però no voleu que ningú sàpigue el vostre password només mirant com escriuen els vostres dits podeu aprofitar aquest sistema.
Referències
- pam_script, home page
- scipt OTP modificat, link a l’script
- paquet amb l’scipt OTP original, link al paquet (local)
- apk del Mobile-OTP (local)
- guia de PAM
- MOTP-AS, Mobile-OTP Authentication Server. RADIUS and PAM support, SQL backend and PHP Web interface.
- Mobile One Time Passwords, strong, two-factor authentication with mobile phones
A tenir en compte en un projecte de digital signage
Tot ordenant .txt he trobat quatre notes que havia fet fa temps extretes de l’experiència i de documents de relacionats amb digital signage que havia anat llegint, per tal de no perdre-les les anoto a continuació:
Entorn:
- Audiència: estàtica o en moviment?
- Predisposició a aturar-se de l’audiència? (area de pas, passeig, etc)
- Cal posar audio? o no dona cap valor afegit.
Audiència:
- Qui mirarà el contingut?
- És una necessitat comuna?
- S’esta buscant algún tipus d’interactivitat, o simplement captació pel missatge emès?
- Què trobarà interessant l’audiència o com a míninm digne de mirar?
- Cuantes vegades un individu veurà el missatge?
- Perquè l’audiència li hauria de donar un segon cop d’ull?
El missatge:
- Venem producte, o un nou estil de vida?
- Creem una atmosfera, o fem marca?
- Cal enumerar els beneficis o podem deixar que les imatges parlin soles?
- Estem informant, instruint, venent o que…?
- És un missatge aïllat o part d’una campanya que usa altres tipus de media?
- Podrien millorar l’experiència enllaços a altres sistemes?
Tips and tricks:
- Intentar crear un sentit de propietat comuna del projecte entre tots els players del negoci
- Audiència en moviment, missatge estàtic. Audiència estàtica, missatge en moviment.
- Monitorització constant de les reaccions de l’audiència.
- S’ha de considerar que l’audiència només donarà una ullada a la pantalla.
- Buscar consistència en els estils i colors del missatge.
- Les tipografies i mides de la lletra han de ser prou clares per llegir-se a certa distància.
- No cal esperar que la publicitat millori de forma espectacular les ventes d’un producte. Només és un complement que ajuda a donar a coneixer el producte.
- Cal assegurar-se que el contingut té una part d’entreteniment i una part d’informació.
- Cal pensar que al montar una pantalla on la gent esta en moviment aquesta ha d’estar en un punt on es pugui seguir movent-se i llegint el missatge.
- Compte amb l’audio, sovint no és una bona idea.
- És important tenir el contingut ben actualitzat i no mostrar informacions obsoletes, això fa perdre credibilitat al medi.
- És important saber l’experiència que té l’audiència sobre el medi.
wiki: Notes sobre entorns de programació
En un .txt tenia unes notes que havia pres sobre entorns de programació, escencialment la conferència de la que són les notes parlava sobre PHP i diferents formens de fer el desplegament dels projectes. Aquesta informació l’he passat a una pàgina del wiki amb la idea d’anar-la actualitzant per altres llenguatges especialment amb la idea de afegir-hi notes de python.
Així doncs l’enllaç del wiki és a: Notes about programming environments and deployment. Tal com podeu deduir amb el títol les notes són amb anglès, sento no recordar la conferència per afegir-hi la presentació.
A continuació enganxo el contingut de la wiki de forma dinàmica, així quan actualitzi la wiki s’actualitzarà l’article:
Entenent els frames I, P i B
Al sentir parlar de formats de video, codecs, DivX, MPEG4, etc. sovint surten a la conversa termes com ara els I-frame, P-frame i B-frame. Cansat de que em soni a xinès he decidit fer-me un petit resum de què és tot plegat, sempre des del punt de vista d’algú que en sap ben poc d’aquests temes.
Podem dividir els ‘frames’ de video en 3 tipus:
- I-Frame: també anomenat keyframe. No té cap frame de referència i pot ser decodificat per si mateix. Podem pensar que és algo semblant a un JPEG.
- P-Frame: El contingut del mateix és dedueix d’un frame previ de tipus I o P, és impossible decodificar-lo sense mirar aquesta referència.
- B-Frame: per decodificar-los cal mirar els frames anteriors i següents de tipus I i P.
Aquest últim tipus de frames són interessant per dues raons:
- Són fàcils de predir
- No impacten en la qualitat dels frames següents
Degut a que els B-frames depenen del passat i el futur, llavors el decodificador li calen frames I-P del passat i el futur per poder decodificar el frame B. Això ens porta als conceptes PTS/DTS.
- PTS Presentation Time Stamp: també podem entendre’l com una forma de saber el número de frame, ordre en que es poden veure els frames decodificats.
- DTS Decoder Time Stamp: ordre en que es processen els frames per ser decodificats.
Un exemple, per entendre-ho millor:
- Suposem que això és un petit video: I-0 B-1 B-2 P-3
- L’ordre DTS seria: I-0 P-3 B-1 B-2
Per tal de simplificar les coses el video s’enmagatzema en l’ordre DTS.
El problema
Arribat en aquest punt podeu imaginar-vos el problema que suposa mostrar un video en ordre, ja que el decodificador ha d’anar composant els frames per mostrar-los am és d’inserir frames on no n’hi han per mostrar el frame que toca.
DIVX (i Xvid)
Aquests famosos codecs per tal de d’atacar aquest problema fan servir un petit truc. La idea seria usar una variant dels frames PB i empaqueten diversos frames en un. Això fa que les aplicacions es pensin que només hi ha un frame i el codec oculta la resta.
Per exemple, si tenim un fitxer que te empaquetat el següent:
In (0 3 1 2) - - - ...
el codec haurà de treure això:
Out 0 1 2 3 ...
El codec posa frames de tipus ‘null’ en el lloc on hi haurien d’haver els frames que no té pel fet de tenir-los empaquetats en un frame. Els codecs ja saben que quan reben un frame null han de descartar-los.
Des del punt de vista del codificador, és important fixar-nos que no s’introdueix un delay corresponent als frames nulls. En un fitxer AVI no hi ha cap relació entre el PTS/DTS guardada enlloc per tal d’informar al decoder quan aquest ha de reproduir.