oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: administrator

Autenticació PAM/OTP via Apache

Reading time: 4 – 6 minutes

L’autenticació d’Apache coneguda com a AuthBasic malgrat la seva inseguretat és una de les més usades, ja que ens permet de forma senzilla i ràpida protegir un directori o simplement un fitxer. La protecció d’aquest tipus d’autenticació és molt relativa perquè el password viatge en clar a través de la xarxa, a més, al viatjar a les capçaleres HTTP o fins hi tot en la propia URL de la pàgina pot arribar a ser indexat per un navegador.

Seguint la línia dels anteriors articles:

Ara el que toca és afegir a l’Apache aquest tipus d’autenticació de forma que podem donar les credencials d’accés a un directori/fitxer a algú però aquestes caducaran al cap del temps (uns 3 minuts) i els buscadors o d’altres agents amb més mala idea no podran accedir al recurs passat aquest temps. Com sempre la idea és la d’aprofitar-se del PAM/OTP.

En primera instància per aconseguir això ho he intentat amb el mòdul libapache2-mod-auth-pam però no n’he tret l’entrellat i he estat incapaç de completar la configuració. Així doncs, el que he fet és provar amb el mòdul libapache2-mod-authnz-external ambdós disponibles en l’Ubuntu 8.04 (Hardy). Aquest segon mòdul l’he combinat amb el checkpassword-pam.

Així doncs, la idea és ben senzilla configurem l’Apache perquè usi el libapache2-mod-authnz-external, en escència el que fa aquest mòdul és recolzar-se en agents externs per fer l’autenticació. Aquest agent extern és el checkpassword-pam que comentava i que com diu el seu nom el que fa és validar el password contra PAM, així doncs, malgrat no és una solució massa eficient a nivell de recursos ja que ha de carregar un segon programa per validar cada usuari considero que és una solució suficienment bona pel meu cas.

La configuració

Instal·lem el mòdul d’apache i l’activem:

apt-get install libapache2-mod-authnz-external
a2enmod authnz_external
/etc/init.d/apache2 restart

Instal·lació del checkpassword-pam

cd /var/tmp
wget "http://downloads.sourceforge.net/project/checkpasswd-pam/checkpasswd-pam/0.99/checkpassword-pam-0.99.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcheckpasswd-pam%2F&ts=1284649515&use_mirror=ignum"
tar xvfz checkpassword-pam-0.99.tar.gz
cd checkpassword-pam-0.99
./configure
make
mkdir -p /opt/checkpassword-pam
cp checkpassword-pam /opt/checkpassword-pam

Fitxer de configuració pel servei apache2 del PAM, /etc/pam.d/apache2:

auth    sufficient      pam_script.so onerr=fail dir=/etc/pam-script.d/
account  required       pam_script.so onerr=fail dir=/etc/pam-script.d/

Si us hi fixeu aquest fitxer és igual al que vaig usar per fer l’autenticació en l’article de PHP i PAM/OTP.

Ara anem a un dels fitxers de configuració d’Apache per un virtualhost i afegim el següent codi per protegir un directori servit per aquest virtualhost:

<Directory /var/www/virtualhost/directori_a_protegir>
  AuthType Basic
  AuthName "Restricted area for My Server"
  require user nom_usuari
  AuthBasicProvider external
  AuthExternal autenticador
</Directory>
AddExternalAuth autenticador "/opt/checkpassword-pam/checkpassword-pam -H --noenv -s php -- /bin/true"
SetExternalAuthMethod autenticador checkpassword

Coses importants a destacar en aquest configuració, fixeu-vos que em cal afegir ‘require user nom_usuari’, això és perquè no disposo de cap fitxer d’usuaris on Apache pugui validar quins són els meus usuaris vàlids i la directiva ‘require valid-users’ no funcionaria, així doncs, hem d’especificar quins usuaris podran fer login a través d’aquesta comanda, o bé, afegir una altre directiva que li permiti a Apache trobar un llistat d’usuaris en algún lloc.

Un altre detall important són els paràmetres que he d’usar al checkpasswords-pam perquè aquest funcioni bé:

  • -H no intenta fer un ‘chdir-home’ ja que potser l’usuari no disposa d’aquest ‘home directory’.
  • –noenv el checkpassword-pam busca certes variables d’entorn per funcionar, amb aquest paràmetre no les busca i agafa el que li cal del stdin.
  • -s apache2 especifica el nom del servei que buscarà dins de /etc/pam.d/apache2
  • — /bin/true simplement serveix perquè el checkpassword-pam no faci res després de validar un usuari, ja que podriem executar algún programa si volguessim després de fer la validació.

Referències

Autenticació PAM/OTP via PHP

Reading time: 2 – 3 minutes

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)

Reading time: 7 – 11 minutes

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

Aufs – la evolució del unionfs

Reading time: 2 – 2 minutes

En les properes setamenes hauré de tornar-me a posar les piles amb els sistemes de fitxers COW(Copy-On-Write), ja havia jugat molt amb unionfs per tal de montar un player linux de digital signage fa uns 2 anys. Però ara estic fent una integració amb MeeGo que porta per defecte el sistema de fitxers BRTFS el qual presenta moltíssimes diferencies en comparació a un sistema de fitxers amb journaling normal com podria ser ext3 i ext4.

La qüestió és que em cal intentar assegurar el bon funcionament d’un sistema operatiu a cada arrencada i havia pensat que potser això podia ser una bona idea, bé ja aniré explicant els resultats del experiments quan toquin. Ara només volia avançar-vos algunes de les funcionalitats i millores que suposa aufs respecte unionfs.

  • permet unir diferents directoris en un directori virtual nou, a cada directori se l’anomenarà una ‘branch’
  • a cada ‘branch’ li podem especificar una ‘flag’ diferent: ‘readonly’, ‘readwrite’ i ‘whiteout-able’
  • gràcies a al nou directori virtual podem simular la capacitat de modificar, afegir i borrar elements en un directori de només lectura
  • suporta la capacitat d’afegir/treure ‘branch’ d’un directori virtual en calent

La llista de funcionalitats és força més llarga però el més important és que el nou aufs és molt més ràpid i confiable que el unionfs.

benchmarking: gearman, couchdb i redis

Reading time: 2 – 3 minutes

No es tracta d’unes proves de rendiment serioses i estríctes, però almenys en el meu cas m’han servit per tenir una idea del rendiment d’aquestes aplicacions i poder dissenyar diferents arquitectures amb una mica més de coneixement de causa.

Per si no coneixeu les eines:

  • gearman: servidor de tasques
  • couchdb: sistema de bases de dades no relacional
  • redis: sistema de caché similar a memcached, però molt millor sota el meu punt de vista

Sistema sobre el que s’han fet les proves:

  • HP ML110 G5 – Xeon 2GHz – 4GB RAM – HD via NFS
    • Rendiment del disc: Timing buffered disk reads:   26 MB in  3.00 seconds =   8.66 MB/sec
  • SO Hypervisor: VMWare ESXi 3.5
  • Servidor virtual: 1 CPU 2GHz i 512Mb RAM
  • SO Guest: Ubuntu 8.04 Hardy

Resultats de les proves:

  • client de gearman, fa 5.000 requests al servidor:
    • gearman backend: default, cua no persistent
      • cmd: gearmand -vvv -u root
      • temps: ~32s – rendiment: ~156req/s
    • gearman backend: sqlite3, cua persistent
      • cmd: gearmand -vvv -u root –libsqlite3-db=/tmp/gearman_sqlite3.cache -q libsqlite3
      • temps: ~11m10s – rendiment: ~0.8req/s
    • gearman backend: tokyo cabinet btree, cua persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tcb -vvv -u root
      • temps: ~2m3s – rendiment: ~40req/s
    • gearman backend: tokyo cabinet hash, cua persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=/tmp/gearmand.tch -vvv -u root
      • temps: ~2m5s – rendiment: ~40req/s
    • gearman backend: tokyo cabinet RAM, cua no persistent
      • cmd: gearmand -q libtokyocabinet –libtokyocabinet-file=”*” -vvv -u root
      • temps: ~17s – rendiment: ~294req/s
  • insertem 5.000 documents a couchdb:
    • temps: ~14s – rendiment: ~357req/s
  • redis fem 10.000 operacions de tipus:
    • SET: temps: ~0.35s – rendiment: ~28.375req/s
    • GET: temps: ~0.59s – rendiment: ~16.920req/s
    • PING: temps: ~0.33s – rendiment: ~30.471req/s

eBox – servidor, gateway i d’altres funcionalitats avançades per PIMES

Reading time: 6 – 10 minutes

ebox-logo.pngL’any 2.006 vaig descobrir eBox, fins hi tot vaig escriure un article que parlava d’ell. Doncs a arrel del article que vaig escriure fa unes setmanes sobre clearOS l’Oriol em va fer pensar altre cop amb l’eBox preguntant-me què tal estava. Doncs bé, la curiositat em va picar i el dilluns el vaig instal·lar en una màquina virtual.

Així doncs a estones durant tota la setmana he estat jugant una mica amb l’eina. En linies generals he de dir que ha millorat moltíssim des de que el vaig descobrir i que integra un munt de funcionalitats noves. La usabilitat continua sent un punt fort de l’eina i també la facilitat d’ús. Jo diria que qualsevol administrador de sistemes de linux en té prou amb uns pocs minuts per sentir-se molt còmode usant l’eina.

Per altre banda no vull deixar de destacar que com a backend per la gestió d’usuaris per tots els serveis que té usa LDAP, cosa que m’ha agradat moltíssim. O sigui, que tenim un postfix, squid, dovecot, asterisk, jabberd2, openvpn, etc. De fet, només això en si mateix ja és un bon motiu per tenir-lo instal·lat en algún racó ja que sempre ens pot anar bé per consultar alguna configuració. A més de poder tenir un esquema d’usuaris per LDAP que podem reaprofitar per integrar en la xarxa de servidors o de desktops. Ja sigui per integrar en el PAM dels linux i/o en l’autenticació dels windows ja que el podem fer treballar com a PDC.

Com ja em va passar amb clearOS, potser el més dolent és que es troben a faltar algunes opcions de configuració que al dissenyar una interficie gràfica simple han hagut d’estalviar-se. Malgrat això l’openVPN disposa de moltes més funcions que no pas el clearOS, a més de la possibilitat d’omplir un camp on podem posar els nostres parametres a mida directament contra el fitxer de configuració. El que ja és impressionant és que integra la possibilitat de poder generar fitxers .exe amb el client d’VPN i totes les configuracions pels clients integrades en l’instal·lador. És a dir, podem generar un fitxer d’instal·lador de l’VPN per cada un dels clients.

A més també vull destacar que disposa d’una PKI propia que per gestionar els certificats dels diferents serveis va molt bé. A més de poder-la utilitzar per generar certificats que després usarem en altres aplicacions ofra del eBox.

Per no seguir fent una valoració desordenada dels serveis que té l’eBox a continuació enganxo la llista de funcionalitats que he trobat a la seva web i al costat hi posaré un comentari a les que ho cregui pertinent.

  • Networking
    • Firewall and routing- bons i simples sistemes de monitorització per la xarxa cosa que sovint es troba a faltar.
      • Filtering – integració força bona de les iptables
      • NAT and port redirections
      • VLAN 802.1Q
      • Support for multiple PPPoE and DHCP gateways – ideal per tenir diverses ADSL en monopuesto.
      • Multi-gateway rules, load balancing and automatic failover – trivialitza aquesta tasca a més de poder-ho configurar fins a un detall força decent.
      • Traffic shaping (with application layer support)
      • Graphical traffic rate monitoring
      • Network intrusion detection system
      • Dynamic DNS client
    • Network infraestructure
      • DHCP server
      • NTP server
      • DNS server
        • Dynamic updates via DHCP
      • RADIUS server – molt agraït el tenir aquesta capacitat per integrar amb linksys o d’altres similars a l’hora de montar un hotspot o per montar autenticacions segures wifi
    • VPN support – molt decent la integració.
      • Dynamic routes autoconfiguration
    • HTTP proxy – forma senzilla de tenir tot el que cal en proxies.
      • Internet cache
      • User authentication
      • Content filtering (with categorized lists)
      • Transparent antivirus
    • Intrusion Detection System – integra SNORT!!! (el vaig usar al meu PFC)
    • Mail Server – un 9!!! una integració molt aconseguida i que fa tot el que li cal a una PIME i més
      • Virtual domains
      • Quotas
      • SIEVE support
      • External account retrieval
      • POP3 and IMAP with SSL/TLS
      • Spam and antivirus filtering
        • Greylisting, blacklisting, whitelisting
      • Transparent POP3 proxy filter
      • Catch-all account
  • Webmail
  • Web server – aquí és on més coixeja el tema sota el meu punt de vista perquè no et deixa tocar pràcticament res del servidor web, o almenys jo no ho he sabut trobar.
    • Virtual hosts
  • Certification authority – realment útil i simple
  • Workgroup
    • Centralized users and groups management
      • Master/slave support
      • Windos Active Directory Synchronization
    • Windows PDC
      • Password policies
      • Support for Windows 7 clients
    • Network resource sharing
      • File server
        • Antivirus
        • Recycle bin
      • Print server
    • Groupware: calendar, address book, webmail, wiki, etc. – personalment no m’agrada gens aquesta eina.
    • VoIP server – poc configurable pel meu gust, però a destacar el ben integrada que esta amb el LDAP, no he sabut veure si tb ho esta amb el XMPP/jabber2.
      • Voicemail
      • Conference rooms
      • Calls through an external provider
      • Call transfers
      • Call parking
      • Music on hold
      • Queues
      • Logs
  • Jabber/XMMP server – això no m’ho esperava, però felicitats per haver-hi pensat.
    • Conference rooms
  • eBox User Corner for self users info updating – va molt bé pq els usuaris s’ajustin el que els cal sense molestar l’administrador.
  • Reporting and monitoring
    • Dashboard for centralized service information
    • Monitor CPU, load, disk space, thermal, memory
    • Disk usage and RAID status
    • Summarized and full system reports
    • Event notification via mail, RSS or Jabber – molt interessant totes les possibilitats de monitorització que té, això val un imperi.
  • Software updates
  • Backups (configuration and remote data backup) – molt simplificada la tasca, no sé què copiara però si ho fa bé, això és brutal.
  • Control Center to easily deploy and administrate several machines running eBox Platform – aquí és on entren les funcionalitats de pagament, ho trobo molt raonable i molt bona idea.

Per acabar he de dir que clearOS hem va agradar moltíssim, potser trobaria algunes coses que les fa millor que l’eBox però he de dir que aquest és realment molt millor que l’altre. En faig una valoració realment positiva i el recomano moltíssim. Això si, si hagués de montar-ne algún en una empresa primer montaria clearOS faria un o dos dies de proves i després montaria eBox per acabar d’estar-ne content. Encara que hagués de pagar aquests dies de feina de la meva butxaca crec que estarien molt ben invertits.

NOTA: Que no se m’oblidi eBox es basa en Ubuntu i clearOS en centOS, malgrat estic familiaritzat amb els .rpm gràcies a Fedora, he de dir que hem sento molt més còmode amb eBox i això pesa molt.

debian/ubuntu: buscant quin paquet conté un fitxer

Reading time: < 1 minute Referència ràpida per saber quin és el paquet en una debian/ubuntu que conté un fitxer. La típica funcionalitat que mai recordes quan et cal: Paquets instal·lats:

dpkg –search /path/fitxer

Fitxers de paquets no instal·lats:

# cal la utilitat apt-file
apt-get install apt-file
apt-file update
apt-file search fitxer

Ubuntu Hardy (8.04) i monit 4.10.1

Reading time: 1 – 2 minutes

El paquet .deb de la versió 4.10.1 del monit no esta disponible per Ubuntu Hardy (v.8.04) el paquet més nou disponible és el 4.8 el problema més greu que suposa això és que no podem usar com servidor de notificacions servidors SMTP sense SSL, per exemple, no es pot usar smtp.gmail.com (gmail.com).

Si voleu instal·lar el paquet 8.10.1 el que s’ha de fer és:

cd /var/tmp
wget http://es.archive.ubuntu.com/ubuntu/pool/universe/m/monit/monit_4.10.1-3_i386.deb
sudo dpkg -i monit_4.10.1-3_i386.deb
monit -V

i veurem l’esperat:

This is monit version 4.10.1
Copyright (C) 2000-2007 by the monit project group. All Rights Reserved.

En cas de voler enviar els correus a gmail la configuració seria algo així:

set mailserver smtp.gmail.com port 587
    username [user]@gmail.com password [pass]
    using TLSV1
    with TIMEOUT 20 seconds

Problemes de rendiment OpenFiler amb VMWare Server [solucionat]

Reading time: 3 – 4 minutes

Després de molts mesos amb un greu problema de rendiment al servidor SAN/NAS de casa que tinc montat en una màqina virtual d’VMWare Server sobre Ubuntu 8.04 LTS, per fi m’he decidit a arreglar el problema. En algún altre post havia comentat el problema, la qüestió és que el rendiment dels 1.5Tb que tinc al servidor des del sistema operatiu de Host és d’uns 70MB/s però les mateixes proves des dels discos gestionats per la màquina Guest, o sigui l’OpenFiler, donaven uns patetis 3, 4 o com a molt 5MB/s. O sigui, que quan s’accedia per NFS o SMB als recursos compartits el rendiment era insuficient i d’altres servidors o màquines que usen aquests recursos se’n veien repercutits.

Finalment després de buscar una mica vaig veure que el problema venia de les interrupcions del sistema que es perdien degut a que el clock rate del servidor Host no era capaç de processar tantes interrupcions. Així doncs, investigant sobre el tema vaig veure que el que cal fer és donar suport HPET, en el meu cas perquè això funcioni ho he hagut d’activar també a la BIOS del HP ML110 que uso com a servidor físic. Amb aquests canvis els tests de velocitat de la màquina virtual amb OpenFiler m’han millorat substancialment i ara mateix donen resultats al voltant de 50MB/s. Obviament, encara estic lluny d’un rendiment òptim però ja no sé si això és tema de configuració o si el problema és més profund i ja depèn de la propia gestió interna que fa l’VMWare amb els mòduls que fan d’interficies entre el hardware real i el virtual.

Si voleu saber si teniu el HPET activat o no al kernel és tan senzill com mirar al dmesg:

root@vm0:~# dmesg |grep hpe
[  120.210408] hpet clockevent registered
[  120.210412] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[  120.210416] hpet0: 3 64-bit timers, 14318180 Hz

En cas de no tenir-lo activat, cal que activeu el següent al fitxer .config del kernel:

CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_RTC=y

A part d’això hi ha d’altres opcions per tal d’acotar aquest tipus de problemes, algunes que permeten estabilitzar les màquines virtuals malgrat no les expremem al màxim ens poden permetre funcionar millor si el rendiment no és el màxim dels nostres problemes i no saturem el Host. Per exemple, es pot afegir al fitxer .vmx de la màquina virtual la següent opció:

host.useFastClock = FALSE

Per cert, si voleu identificar el problema el kernel de la màquina Host dona errors de l’estil:

Aug 21 12:56:11 dey kernel: rtc: lost some interrupts at 2048Hz.

o també coses així:

select() to /dev/rtc to wait for clock tick timed out.

Com sempre a google podeu trobar moltíssima informació de com ajustar el vostre Linux perquè rendeixi al màxim amb VMWare. Per la meva part, ara hem queda posar en marxa mil i una coses que depenien d’aquest servidor de fitxers que mica en mica anava obligant-me a parar serveis per manca de rendiment. Espero que properament ja pugui posar en marxa funcions com l’album de fotografies i d’altres similars.

spacewalk – el RedHat Network Satellite alliberat

Reading time: 4 – 6 minutes

spacewalk logoNo sóc un gran coneixedor dels productes de RH, ni tampoc de Fedora ni CentOS. Malgrat això per temes de Kerberos, LDAP i d’altres similars m’estic endinsant força en aquest món. Doncs bé, el dia 20 de juny la gent de RH van alliberar el codi del RedHat Network Satellite al project l’han anomenat spacewalk. Després d’una bona estona llegint la seva documentació volia comentar que la idea que proposen i el nivell d’integració que té l’eina és molt bona, malgrat això he de dir que no hem serveix de gran cosa degut a que esta massa orientat a distribucions amb sistemes de paquets .rpm, o sigui, la propia RH i Fedora sobretot, de CentOS i la resta en parla ben poc.

Cal dir però que les funcionalitats que ofereix són relment una font d’inspiració per d’altres productes que algún dia algú haurà de dissenya per distribucions basades en .deb, o sigui, debian i ubuntu bàsicament.

Llistat de funcionaltats de l’spacewalk:

  • Inventory your systems (hardware and software information)
  • Install and update software on your systems
  • Collect and distribute your custom software packages into manageable groups
  • Provision (kickstart) your systems
  • Manage and deploy configuration files to your systems
  • Monitor your systems
  • Provision and start/stop/configure virtual guests
  • Distribute content across multiple geographical sites in an efficient manner.

A continució ús dono una petita llista d’eines que malgrat no estar tan ben integrades com l’spacewalk i sovint no disposar de bones interficies poden ser un bon punt per començar a solucionar alguns problemes:

  • puppet: basada en un llenguatge ruby com a llenguatge d’scripting per llençar funcions remotament contra sistemes remots, l’eina és realment potent però la veig poc integrada amb el sistema operatiu i es basa molt en funcions com expect per capturar les sortides de les comandes de sistema executades remotament. A més considero que no té un bon sistema d’informes per saber com ha anat el deploy.
  • capistrano: molt semblant a puppet, tan és així que usa també ruby com a llenguatge d’scripting i tots els problemes comentats antiriorment els hi veig també a aquest. Té una mica més ben resolt el tema del feedback dels deploys però sota el meu punt de vista no acaba de ser suficient.
  • func: projecte que també ve de RH i que té el codi alliberat, actualment en fan el manteniment la gent de Fedora. Es basa en Python com a llenguatge d’scripting i ofereix tota una API per la gestió de comandes remotes, ben pensat per xarxes grans ja que permet llençar comandes de forma asícrona. Disposa d’una molt bona integració amb el sistema operatiu gràcies a la gran quantitat de bindings que te Python. Per exemple, com que és un producte de fedora només disposa de binding genèric de yum per instal·lar paquets remotament,  però gràcies a que el llenguatge d’scripting és Python és molt senzill crear un mòdul de func que enllaci amb python-apt i permetre instal·lar paquets a una ubuntu. Aquesta bona integració permet controlar els feedbacks d’una forma molt eficients malgrat no disposa d’eines d’informes pròpies.
  • fai: és una eina pensada per fer instal·lacions automàtiques de distribucions linux o de sistemes de clusters, ja siguin virtualitzats o amb màquines reals. El projecte té uns grans avals i porta moltíssims anys online i actiu. Per tant, dona moltíssima confiança. El dolent és que no sembla trivial d’usar i malgrat té una eina per monitoritzar l’estat del deploy és basa moltíssim en CLI. No he vist cap GUI que en faciliti l’ús excepte GOSA, el qual és un projecte molt ampli d’LDAP bàsicament usat per la migració a Linux de l’ajuntament de Berlin.
  • cobbler: una eina molt semblant a fai, però de la gent de RH i amb el codi alliberat. Té molt bona pinta i a més s’integra amb func. No l’he estudiat a fons encara per saber on té els punts febles, ja que com sempre el que més por fa és la dependència de paquets .rpm; malgrat això disposa d’una interficie web per la gestió, línia de comandes i API en python per extendre les seves funcionalitats i sempre es podria lligar una instal·lació cobbler amb func perquè fos compatible amb ubuntu tal com havia comentat abans.