De vegades ens interessa refrescar el “caché” de dns per exemple quan modifiquem el fitxer /etc/hosts, per a fer-ho en leopard:
1 2 |
# El que abans era: lookupd -flushcache dscacheutil -flushcache |
Segons el man:
dscacheutil does various operations against the Directory Service cache including gathering statistics, initiating lookups, inspection, cache flush, etc. This tool replaces most of the functionality of the lookupd tool previously available in the OS.
Leopard porta tot l’entorn de desenvolupament per a Ruby on Rails i Ruby integrat, cosa que està molt bé ja que facilita enormement l’arrencada de la gent que comença a desenvolupar amb aquestes tecnologies.
La versió de Ruby instal·lada es la 1.8.6 (amb alguns patchs interessants com ara el de suport per a dtrace). Algunes distribucions com ara centos 5 o debian etch utilitzen la versió 1.8.5. Això vol dir que si tenim aplicacions en producció corrent sobre aquestes distribucions probablement voldrem desenvolupar sobre la mateixa versió de Ruby per tal d’evitar “sorpreses”.
Per a aconseguir això podem compilar directament dels fonts o utilitzar macports. La cosa es que en el cas de voler utilitzar macports ens trobarem que no existeix variant per la versió 1.8.5.
El que podem fer es crear el nostre port a partir de la revisió de subversion del repositori macports del port de ruby que es corresponia a la versió 1.8.5:
Primer hem de crear un repositori de ports local:
1 2 |
mkdir /Users/Shared/dports sudo sed -e '1i file:///Users/Shared/dports' -i~ /opt/local/etc/macports/sources.conf |
Seguidament treiem la versió del repositori que ens interessi:
1 2 3 |
cd /Users/Shared/dports svn co --revision 21487 http://svn.macports.org/repository/macports/trunk/dports/lang/ruby/ lang/ruby/ portindex /Users/Shared/dports |
Llavors en un món ideal ja podríem instal·lar fent:
sudo port install ruby |
I això instal·laria la versió del port en el nostre repositori local (1.8.5), el que passa es que per a que Ruby funcioni en Leopard cal aplicar uns patchs d’apple al codi font segons s’explica aquí
Així doncs el que caldrà fer es descarregar els fitxers dels patchs al directori files del nostre port i modificar el fixter Portfile per a que els apliqui. Si fem això veurem que s’apliquen netament excepte un que falla degut a que aquests patchs estan pensats per a la versió 1.8.6 de Ruby.
El que cal fer quan falla la instal·lació és anar al directori de treball del port, revisar el patch que falla i veure si podem modificar-lo per a aplicar-lo a la versió 1.8.5.
La modificació és molt senzilla, es tracta del fitxer ignore-gsetcontext.diff i un cop modificat per a la versió 1.8.5 queda així:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
--- eval.c.orig 2007-10-31 12:03:10.000000000 +0100 +++ eval.c 2007-10-31 12:03:10.000000000 +0100 @@ -29,9 +29,17 @@ #endif #include <stdio> -#if defined(HAVE_GETCONTEXT) && defined(HAVE_SETCONTEXT) -#include <ucontext> -#define USE_CONTEXT +#if defined(HAVE_GETCONTEXT) && defined(HAVE_SETCONTEXT) +# if defined(__APPLE__) +# include <availabilitymacros> +# if MAC_OS_X_VERSION_MAX_ALLOWED <= 1040 +# include <ucontext> +# define USE_CONTEXT +# endif +# else +# include <ucontext> +# define USE_CONTEXT +# endif #endif #include <setjmp> |
Arribats a aquest punt podem instal·lar el port amb la comanda habitual:
sudo port install ruby |
Un cop fet tot això disposarem de 2 versions de ruby instal·lades la 1.8.6 que es la que ve per defecte en Leopard i la 1.8.5 que es la que hem instal·lat via macports.
Podem fer servir una o altra segons ens convingui en funció de l’ordre de càrrega dels binaris de macports en la nostra variable PATH, si posem primer la de macports (/opt/local/bin i /opt/local/sbin) s’utilitzarà per defecte la versió 1.8.5 de Ruby i en cas contrari la 1.8.6.
Solaris disposa d’algunes característiques molt interessants, per a mi destaquen sobretot dtrace i el sistema de fitxers ZFS.
Pel que fa a ZFS la seva llicència fa impossible un port per a Linux, si bé sembla que es pot utilitzar mitjançant FUSE tal i com s’explica a ZFS on FUSE/Linux.
Per a Linux en comptes de dtrace tenim systemtap que proporciona funcionalitats similars. Podem veure una taula comparativa que detalla les diferències entre ambdós sistemes.
De moment no es possible d’utilitzar-lo en llenguatges script com ruby o python (cosa que si és possible amb dtrace).
Per a instal·lar systemtap en Centos 5 solament hem de fer:
yum install systemtap |
A més també haurem d’instal·lar els paquets:
Les versions dels 2 darrers paquets s’han de correspondre amb la versió de kernel instal·lada i es poden trobar aquí
Amb systemtap podem fer coses força interessants, per exemple amb l’script següent podem veure una llista de processos ordenada en funció de l’ample de banda de xarxa que consumeixen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
global ifxmit, ifrecv, ifdevs, ifpid, execname, user
probe netdev.transmit
{
p = pid()
execname[p] = execname()
user[p] = uid()
ifdevs[p, dev_name] = dev_name
ifxmit[p, dev_name] <<< length
ifpid[p, dev_name] ++
}
probe netdev.receive
{
p = pid()
execname[p] = execname()
user[p] = uid()
ifdevs[p, dev_name] = dev_name
ifrecv[p, dev_name] <<< length
ifpid[p, dev_name] ++
}
function print_activity()
{
printf("%5s %5s %-7s %7s %7s %7s %7s %-15s\n",
"PID", "UID", "DEV", "XMIT_PK", "RECV_PK",
"XMIT_KB", "RECV_KB", "COMMAND")
foreach ([pid, dev] in ifpid-) {
n_xmit = @count(ifxmit[pid, dev])
n_recv = @count(ifrecv[pid, dev])
printf("%5d %5d %-7s %7d %7d %7d %7d %-15s\n",
pid, user[pid], dev, n_xmit, n_recv,
n_xmit ? @sum(ifxmit[pid, dev])/1024 : 0,
n_recv ? @sum(ifrecv[pid, dev])/1024 : 0,
execname[pid])
}
print("\n")
delete execname
delete user
delete ifdevs
delete ifxmit
delete ifrecv
delete ifpid
}
probe timer.ms(5000)
{
print_activity()
} |
Un exemple de la sortida si l’executem:
1 2 3 4 |
PID UID DEV XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND 0 0 eth0 0 13 0 2 swapper 1947 501 eth0 4 0 0 0 ping 1873 0 eth0 1 0 0 0 sshd |
Podem veure més exemples d’scripts en el wiki.
Per si voleu anar seguint les sessions de la Railsconf, aquest enllaç us pot resultar interessant.
Avui hi han hagut sessions molt interessants a veure si més tard tinc temps de donar-ne la meva opinió i fer-ne un breu resum.
Aquest “tutorial” estava a càrrec d’en Jason Hoffman de Joyent . La veritat es que d’entrada prometia bastant ja que ells porten alguns dels “deployments” d’aplicacions Rails de més gran escala en l’actualitat com ara twitter per exemple.
La sessió ha tractat desde la selecció de servidors, consideracions de consum d’energia, costos d’ample de banda a alguns temes més específics d’aplicacions Rails.
Personalment pensava que tractaria més a fons temes específics sobre les bones pràctiques a l’hora d’escalar aplicacions Rails però les 2 primeres hores s’han centrat en temes de caire general, malgrat això la darrera hora ha estat prou interessant.
Algunes coses que he trobat especialment interessants:
Evidentment s’han tractat molts d’altres temes: com escalar la base de dades, Jruby o la separació dels controladors de la nostra aplicació amb mongrels específics.
En resum molt interessant però he trobat a faltar certa manca de profunditat a l’hora de tractar temes més específics de Rails.
Ha sortit una nova versió (la 0.9.9) de JRuby , i això és important ja que aquesta iniciativa pot facilitar l’entrada de Ruby i de Rails als entorns més “enterprise” al permetre l’utilització de la infraestructura Java/J2EE existent.
Bàsicament podem fer correr aplicacions rails (i d’altres ruby) en servidors com ara Tomcat, a més de disposar de facilitats extres per a accedir a llibreries de java (aquesta sembla ser la idea).
Si hi voleu donar un cop d’ull i comprovar que tal funcionen les vostres aplicacions Rails podeu descarregar la versió binària
Llavors podeu afegir quelcom així al vostre profile:
1 2 |
export JRUBY_HOME=/cami/al/directori/jruby-0.9.9 export PATH=totelquejatenim:$JRUBY_HOME:$PATH |
Després des del directori on heu descomprimit l’arxiu:
1 2 3 4 5 |
bin/gem install rails chmod +x bin/rails bin/rake bin/rails testapp cd testapp jruby script/server |
Fer el deploy en un tomcat o similars tampoc es massa complicat.
La versió 1.0 s’acosta i aplicacions com ara Mephisto ja funcionen. Es nota l’empenta del projecte des que Sun va decidir de contribuir-hi
A gnuine, l’empresa on treballo, estem buscant certs perfils que per la relació amb Ruby on Rails he pensat que potser podien interessar a algú de vosaltres.
Adjunto un extracte:
Programador
Treballaràs amb Ruby on Rails, però no es necessària experiència prèvia amb el framework, pero si en altres llenguatges com PHP, Python, Perl o Java.
Valorarem especialment:
Administrador de sistemes
Treballaràs amb GNU/Linux de forma exclusiva, administrant sistemes en producció (clusters de servidors, replicació de base de dades, etc …) i participant activament en la implementació de noves plataformes i solucions tecnològiques.
Valorarem especialment:
Per a més informació, podeu visitar la web de gnuine
Micro-script ruby per a utilitzar a la comanda useradd amb la opció -p a la que hem de passar el password encriptat. Bàsicament això pot ser útil per a la creació automatitzada d’usuaris de sistema.
1 2 |
#!/usr/bin/ruby print ARGV[0].crypt("seedtext") if ARGV.size == 1 |
Aquest script reb com a parametre el password de debò i retorna la versió encriptada, exemple d’ús suposant que hem anomenat crypt al script:
useradd -m -k /etc/myskel -g mygroup -p `pwgen | awk {"print $1"} | xargs ./crypt` -d /home/testuser2 testuser2 |
Els generadors son una peça molt important de rails i una d’aquelles que es fan servir constantment.
Per exemple cada cop que executem una comanda com ara:
1 2 |
script/generate model User script/generate controller user |
Estem executant el que rails anomena generador, que el que fa es generar codi per nosaltres, això contribuix a accelerar el cicle de desenvolupament i a lliurar-nos de tasques tedioses i repetitives.
La generació de codi no es un tema nou, vull dir que tots els que ens dediquem al món del desenvolupament l’hem utilitzat en major o menor mesura, el que potser no era tan habitual era la seva utilització en frameworks de desenvolupament.
Podem crear els nostres propis generadors, per exemple podem veure com crear-ne un que ens ajudi amb les configuracions de mongrel, apache, deploy i rotació de logs.
Seguir llegint...Ja fa temps que coneixia que el capistrano disposa de la opció de configurar un servidor com a gateway a l’hora de fer els deploys. Bàsicament estableix primer una conexió al gateway i després fent ssh forwarding als servidors reals on cal fer els deploys.
Això el que ens permet es poder fer deploys a servidors als quals no tenim accés ssh obert a la nostra màquina utilitzant un servidor, al que si tenim accés, com a gateway. Una situació molt comú. La opció és:
set :gateway, "my.gateway.com" |
Doncs bé no havia necessitat quelcom així més que res perquè a la empresa on treballo disposem d’una eina propia de deploys automatitzats i ja tenim el tema molt solucionat desde ja fa temps.
Avui doncs ho he hagut de fer servir i funciona com la seda, per a més detalls de la implementació podeu consultar el següent article
