Revisar:
- php.ini: date.timezone = America/Lima
- /usr/share/zoneinfo/America/Lima debe estar dentro de chroot
- Usar "127.0.0.1" como db host en config.php en lugar de "localhost"
(el socket no está disponible dentro de chroot)
miércoles, 27 de enero de 2021
Moodle, Jailkit y php-fpm
jueves, 21 de mayo de 2020
Problemas con Grub2
Un simple reinicio luego de una actualización de kernel y el servidor no arrancaba.
Ejemplo de comandos a usar desde grub:
ls (hd2,2)/ es lo mismo que ls (hd2,msdos2)/ o ls (hd2,gpt2)/
Se debe buscar en cuál unidad está /boot con archivos vmlinuz-* e initramfs-*
set root=(hd0,1)
linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1
initrd /boot/initrd.img-3.13.0-29-generic
boot
/dev/sda1 debe corresponder a la unidad que aloja a la raíz. En el caso de discos ssd puede ser algo como /dev/nvme0n1p2, lo mejor es revisar /etc/fstab, por ejemplo (estando en grub): cat (hd2,2)/etc/fstab
Al reiniciar el sistema podría quedarse en modo de mantenimiento. Se debe corregir el problema de grub2 y hacer permanentes los cambios. Lo primero es ver una lista de kernels disponibles:
cat /etc/grub2.cfg | grep ^menuentry
La lista de kernels se cuenta desde 0. El primero de la lista es el 0. Es importante porque se debe elegir cuál se usará:
grub2-set-default 0
Luego:
grub2-mkconfig -o /boot/grub2/grub.cfg
Y finalmente:
grub2-install /dev/sda
Ojo que no es /dev/sda1 porque no se refiere a una partición, sino a una unidad entera.
En el caso de una partición /dev/nvme0n1p2, el nombre de la unidad sería /dev/nvme0n1
Ejemplo de comandos a usar desde grub:
ls (hd2,2)/ es lo mismo que ls (hd2,msdos2)/ o ls (hd2,gpt2)/
Se debe buscar en cuál unidad está /boot con archivos vmlinuz-* e initramfs-*
set root=(hd0,1)
linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda1
initrd /boot/initrd.img-3.13.0-29-generic
boot
/dev/sda1 debe corresponder a la unidad que aloja a la raíz. En el caso de discos ssd puede ser algo como /dev/nvme0n1p2, lo mejor es revisar /etc/fstab, por ejemplo (estando en grub): cat (hd2,2)/etc/fstab
Al reiniciar el sistema podría quedarse en modo de mantenimiento. Se debe corregir el problema de grub2 y hacer permanentes los cambios. Lo primero es ver una lista de kernels disponibles:
cat /etc/grub2.cfg | grep ^menuentry
La lista de kernels se cuenta desde 0. El primero de la lista es el 0. Es importante porque se debe elegir cuál se usará:
grub2-set-default 0
Luego:
grub2-mkconfig -o /boot/grub2/grub.cfg
Y finalmente:
grub2-install /dev/sda
Ojo que no es /dev/sda1 porque no se refiere a una partición, sino a una unidad entera.
En el caso de una partición /dev/nvme0n1p2, el nombre de la unidad sería /dev/nvme0n1
lunes, 18 de mayo de 2020
Cuando los programas que usan la librería ncurses, se ven mal
Tratando de usar ncdu (una excelente herramienta para averiguar de qué está lleno el disco), me encuentro con que su interface se ve mal, por caracteres gráficos incorrectamente mostrados.
Este problema ocurre en CentOS 7 con cualquier programa que use la librería ncurses y la solución consiste en crear un archivo /etc/profile.d/ncurses.sh que contenga:
export NCURSES_NO_UTF8_ACS=1
En el siguiente inicio de sesión, la aplicación ya será mostrada correctamente.
lunes, 8 de diciembre de 2014
Actualizar de PHP 5.3 a PHP 5.4 usando CentOS y Virtualmin para poder usar Moodle 2.7 o posteriores.
Hace poco tuve que actualizar Moodle a 2.8+ y utilice el repo de Remi tal como dicen en otros posts que se encuentran al googlear.
El problema es que al final, los sites no cargaban, sólo páginas en blanco.
Encontré este link:
http://reviews.myhken.com/upgrading-php-from-5-3-x-to-5-4-x-or-5-5-x-on-centos-6-5-with-virtualmin/
Y aunque funciona bien parcialmente, el problema es que los sites corriendo como php_mod ya no funcionaban.
Lo resolví así:
Renombré /etc/httpd/conf.d/php.conf como php.conf.no tal como decían en el link.
Pero en su lugar copié php.conf de otro servidor que aún tenía php 5.3:
El problema es que al final, los sites no cargaban, sólo páginas en blanco.
Encontré este link:
http://reviews.myhken.com/upgrading-php-from-5-3-x-to-5-4-x-or-5-5-x-on-centos-6-5-with-virtualmin/
Y aunque funciona bien parcialmente, el problema es que los sites corriendo como php_mod ya no funcionaban.
Lo resolví así:
Renombré /etc/httpd/conf.d/php.conf como php.conf.no tal como decían en el link.
Pero en su lugar copié php.conf de otro servidor que aún tenía php 5.3:
#
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
#
LoadModule php5_module modules/libphp5.so
LoadModule php5_module modules/libphp5-zts.so
#
# Cause the PHP interpreter to handle files with a .php extension.
#
AddHandler php5-script .php
AddType text/html .php
#
# Add index.php to the list of files that will be served as directory
# indexes.
#
DirectoryIndex index.php
#
# Uncomment the following line to allow PHP to pretty-print .phps
# files as PHP source code:
#
#AddType application/x-httpd-php-source .phps
Y nada más, ya no modifiqué /etc/httpd/conf/httpd.conf para quitar las líneas que empezaran por php_ (ni reemplazándolas por #php_).
Aparentemente todo el problema es causado por las líneas SetHandler del nuevo archivo php.conf.
Con esta configuración, funciona PHP 5.4 con cualquiera de los tres modos: mod_php, cgi o fcgi.
De todos modos, la instalación de Moodle la tuve que hacer con el modo CGI:
https://moodle.org/mod/forum/discuss.php?d=221196
sábado, 26 de abril de 2014
Tener un televisor full-hd y no poder elegir la resolución correcta desde Windows
¿Te ha pasado que tienes una pantalla full-hd pero al conectarla a tu laptop con un cable VGA sólo puedes elegir hasta 1366x768 o alguna otra resolución inferior? ¿O te pasa que la imagen se ve estirada, distorsionada o borrosa? ¿Notas que las letras no se ven con la misma nitidez que en la pantalla de la laptop?
Esto ocurre cuando Windows no puede manejar correctamente la pantalla, porque esta última le da información errada sobre sus características. Existe una pequeña herramienta gratuita llamada Custom Resolution Utility (CRU) que puede resolverlo.
Resulta muy fácil: ejecutamos el programa del link mencionado antes, descomprimimos el zip (no hace falta instalarlo) y ejecutamos cru.exe. La imagen que veremos será como esta:
En la parte superior hay un selector donde deberemos elegir la pantalla que queremos modificar. En la imagen mostrada ya he seleccionado mi pantalla LCD y ya he agregado una resolución que no estaba disponible: 1920x1980 (16:9) @ 60 Hz. Para ello todo lo que hay que hacer es usar el botón ADD de la lista "Standard resolutions":
Elegimos la resolución full-hd tal como se muestra, pulsamos OK para regresar a la ventana principal y estando allí volvemos a pulsar OK. Reiniciamos el equipo y listo, problema resuelto!
Si deseas saber por qué ocurre, aquí una breve explicación: las pantallas plug & play comparten información sobre sus capacidades mediante un formato de datos llamado EDID (Extended display identification data). Algunas pantallas brindan información incompleta o incorrecta, lo que causa que Windows no pueda manejar correctamente el dispositivo.
Es posible proporcionarle manualmente a Windows estos datos (lo mismo que haría un driver), pero implica manipular el registro. Aquí es donde CRU nos resulta muy útil, ya que nos permite fácilmente "agregar" una resolución específica que teóricamente nuestra pantalla no soporta. Por supuesto debemos tener cuidado porque algunas pantallas muy antiguas podrían incluso averiarse, pero cualquier televisor decente mostrará un aviso de "resolución no soportada".
sábado, 22 de junio de 2013
Evitar que YUM actualice ciertos paquetes
Directo al grano:
Para evitar actualizar -por ejemplo- tomcat, en /etc/yum.conf agregar la línea
exclude=tomcat*
Ahora los rodeos que normalmente irían antes:
Algunas veces ocurre que tenemos una configuración especial en un servidor o equipo. Algo que es mejor no tocar porque es demasiado crítico. O también puede ser que pretendamos mantener una versión específica de ciertos programas, para pruebas de compatibilidad.
Me pasó con un cliente que utilizaba mailman para distribuir información bursatil muy importante. Un buen día la distribución no funcionó y no había tiempo para investigaciones. No tuve más remedio que "retroceder" el sistema a un estadio previo (menos mal que era una VM de la cual tenía backup).
La solución fue simple (CentOS 6.4), en /etc/yum.conf agregué
exclude=mailman*
Santo remedio, nunca más se actualizó (ni ofreció actualizar) mailman.
Y si se trata de mantener un sistema sin actualizar, se puede desactivar los repositorios básicos de yum. En /etc/yum.repos.d existen archivos por cada repositorio. Se puede crear excludes en cada uno de ellos (a diferencia del anterior que es global). O se puede desactivar completamente un determinado repositorio (enable=0) mientras que otros quedan activos.
Por ejemplo, en mi caso desactivé los repositorios base de CentOS pero (por ser una VM manejada con Cloudmin/Virtualmin) mantuve activo el repositorio virtualmin-universal porque actualiza el manejador de la máquina virtual pero no el sistema operativo.
martes, 3 de julio de 2012
Máquinas Virtuales
Una máquina virtual (VM por Virtual Machine) es un entorno de software que recrea las características de un equipo real de modo que podamos -para decirlo en términos simples- tener una computadora dentro de otra. Una máquina virtual tiene su propio Bios, hardware y sistema operativo con independencia de lo que utilice la máquina real que la aloja.
Las aplicaciones son variadas, desde emular entornos de hardware no disponibles por antiguedad, precio, etc. hasta consolidar múltiples equipos en uno sólo con fines de ahorro o simplificación de administración.
Recientemente, nos hemos aventurado a utilizarlo con un fin más interesante: nuestros servidores de hosting compartido. Las ventajas son enormes, especialmente por la forma en que VIS organiza sus servicios.
Concentrar todos los servicios en un único servidor es una pésima idea.
Separar todos los servicios en equipos independientes es muy costoso.
Una buena opción es agrupar los servicios en dos o tres equipos.
Una opción mucho mejor es separar todo en máquinas virtuales y distribuirlas en los mismos dos o tres equipos reales. ¿Por qué?
Las ventajas son muchas:
- La administración puede ser más refinada y precisa: se puede afinar al detalle los servicios o mantenerlos separados y controlados de manera que no interfieran entre ellos.
- Se puede ajustar los recursos asignados a cada servicio según la demanda lo requiera. Incluso se puede independizar un servicio en un equipo real independiente si el consumo así lo requiere.
- Se puede "clonar" equipos muy fácilmente, con toda la configuración ya lista.
- El costo no se eleva significativamente pero sí se requiere mayores conocimientos para poder administrar el conjunto.
- Migrar a equipos más potentes se reduce a mover la máquina virtual de un equipo a otro.
Existen muchas plataformas de virtualización en constante desarrollo, algunas comerciales, otras de código abierto: VMware, Hyper-V, KVM, VirtualBox, Xen, etc.
Como siempre, es cuestión de darse el tiempo -nunca suficiente- para experimentar con ellas y ver la forma de sacarles provecho.
Hosting compartido: ¿Todos los huevos en una sola canasta?
El hosting tradicional consiste en tomar UN servidor, instalarle un panel de control (cpanel en el 99% de los casos), agregarle todos los servicios necesarios (correos, webmail, sitios web, bases de datos, listas, filtros anti-spam, etc.) y repartir el acceso entre una determinada cantidad de clientes.
Suele suceder que -por ahorro de costos- se agregan demasiados clientes a un único servidor y entonces los problemas de rendimiento se agravan.
Imaginen a una sola persona que debe atender el teléfono, tomar notas de una reunión, escribir una carta, calcular los impuestos a pagar, atender a un cliente presencialmente, etc. todo al mismo tiempo. Basta que alguna de esas actividades le demande demasiada atención para que inevitablemente descuide las otras.
Es lo que sucede si al mismo servidor se le instalan cosas tan diferentes como una base de datos, un servidor de correo y un servidor web. Basta que a un usuario se le ocurra abrir un buzón muy grande o que el filtro anti-spam deba analizar un mail con attachments muy pesados o que un sitio web deba realizar una tarea pesada, para que el resto de servicios se vean afectados.En una situación ideal, tendríamos varios servidores, uno por cada tarea de modo que puedan estar especialmente configurados para realizarla de la mejor manera. Siendo más servidores, pueden manejar una mayor cantidad de usuarios, lo que en cierta forma compensa el costo adicional, pero no evita que el conjunto sea más complicado de manejar. El principal problema es que las herramientas comúnmente utilizadas para administración (por ejemplo: cpanel) no están concebidas para este tipo de operación, por lo que simplemente los proveedores optan por el único camino que tienen (todo en el mismo server).
Como los extremos nunca son buenos, una solución intermedia aceptable es utilizar al menos dos servidores: uno para correo y otro para web. El servidor de correo puede concentrarse en los servicios SMTP, POP3, IMAP y quizá su propio webmail. El otro puede concentrarse en el sitio web (apache, php y mysql).
Otras tareas que demandan un elevado consumo de recursos de procesamiento pueden ser delegadas a servidores especializados. El mejor ejemplo es el filtrado anti-spam.
VIS emplea un esquema similar al mencionado, empleando no uno sino dos servidores de filtrado para todos sus servidores de correo. Funciona muy bien y permite realizar una serie de complejos procesos sin mayor impacto en el nivel de servicio, aunque muchas veces resulta complicado explicarle a un potencial nuevo cliente por qué un servicio cuesta significativamente más que el otro.
Conclusión: es mejor usar varios servidores especializados en determinadas tareas. Concentrar todos los servicios en un único equipo es una bomba de tiempo.
viernes, 19 de febrero de 2010
Made in Perú
He pasado las últimas 3 horas leyendo diversos webs, blogs, etc. sobre desarrollo de software en Perú. Con tanto trabajo algunas veces olvidamos darnos un baño de información nueva. ¿Mi conclusión? Mucho floro, palabreo y sigla bonita, pero muy poco desarrollo realmente peruano.
Drupal, Joomla, etc. ganan terreno. Veo con pánico cómo la historia de los ochentas a noventas parece repetirse: luego de un inicio humilde pero auspicioso, caemos en el facilismo de simplemente usar lo que otros producen en el extranjero.
Sólo basta navegar por los sitios web de los principales medios, tal parece que crear aplicaciones web se está convirtiendo en cuestión de crear skins, adecuar estilos y algunos plugins?
En los ochentas, cuando reinaban las computadoras de 8 bits, hubo algunos pocos que le encontraron el gusto a la programación. De esos pocos, un número aún menor se organizó en pequeños grupos que intentaban crear pequeñas producciones netamente peruanas. Era usual comprar revistas españolas de muy buena calidad sobre computación, donde además de aprender, se podía mirar de lejos la gran actividad del joven mundo informático en Europa.
Yo tenía 14 años cuando quedé sorprendido al encontrar en El Comercio un aviso buscando programadores que manejaran assembler, con el cuál yo había estado jugando/descubriendo desde hacía pocos meses. Por supuesto que fui y en verdad estos tipos sabían del asunto, se hacían llamar "Software Home" y antes que nada me pidieron que mostrara lo que había hecho (un muy simplón juego de serpientes come-números, pero escrito en assembler, que me había costado sangre!). Espero haberles causado una buena impresión, el hecho es que luego me mostraron lo que estaban creando y fue impresionante! Un video juego a la altura de los que llegaban del extranjero. Por diversas razones luego de un tiempo no supe más de ellos. Otros como TEG (hoy Tegmo.com) continuaron la pelea.
Todo ese mundo murió con la masificación de las PCs y terminamos simplemente consumiendo software pirata.
Lo que no he perdido es la convicción de que más que simplemente usar, se debe crear. Por eso VIS emplea su propio framework, para poder controlar cada aspecto a nuestro antojo. Desde hace casi 10 años lo hemos usado para incontables proyectos en diferentes encarnaciones y nos ha permitido diferenciarnos y poder transferir a cada cliente, la experiencia del proyecto anterior, siempre mejorando nuestro arsenal de herramientas.
Esperemos que el tema comercial no termine -otra vez- convirtiéndonos en simples consumidores. En nuestro medio es muy común "seguir a la manada", usando siglas, abreviaturas, etc. casi como alarde de que supuestamente conocemos un tema. Aquí los "monstruos en computación" usan Firefox, instalan Linux, recompilan Kernels y hasta "hackean" messengers :) pero son contados los que realmente entienden por qué lo hacen, menos aún los que modifican código o crean patchs. Ni qué decir de creaciones propias.
Drupal, Joomla, etc. ganan terreno. Veo con pánico cómo la historia de los ochentas a noventas parece repetirse: luego de un inicio humilde pero auspicioso, caemos en el facilismo de simplemente usar lo que otros producen en el extranjero.
Sólo basta navegar por los sitios web de los principales medios, tal parece que crear aplicaciones web se está convirtiendo en cuestión de crear skins, adecuar estilos y algunos plugins?
En los ochentas, cuando reinaban las computadoras de 8 bits, hubo algunos pocos que le encontraron el gusto a la programación. De esos pocos, un número aún menor se organizó en pequeños grupos que intentaban crear pequeñas producciones netamente peruanas. Era usual comprar revistas españolas de muy buena calidad sobre computación, donde además de aprender, se podía mirar de lejos la gran actividad del joven mundo informático en Europa.
Yo tenía 14 años cuando quedé sorprendido al encontrar en El Comercio un aviso buscando programadores que manejaran assembler, con el cuál yo había estado jugando/descubriendo desde hacía pocos meses. Por supuesto que fui y en verdad estos tipos sabían del asunto, se hacían llamar "Software Home" y antes que nada me pidieron que mostrara lo que había hecho (un muy simplón juego de serpientes come-números, pero escrito en assembler, que me había costado sangre!). Espero haberles causado una buena impresión, el hecho es que luego me mostraron lo que estaban creando y fue impresionante! Un video juego a la altura de los que llegaban del extranjero. Por diversas razones luego de un tiempo no supe más de ellos. Otros como TEG (hoy Tegmo.com) continuaron la pelea.
Todo ese mundo murió con la masificación de las PCs y terminamos simplemente consumiendo software pirata.
Lo que no he perdido es la convicción de que más que simplemente usar, se debe crear. Por eso VIS emplea su propio framework, para poder controlar cada aspecto a nuestro antojo. Desde hace casi 10 años lo hemos usado para incontables proyectos en diferentes encarnaciones y nos ha permitido diferenciarnos y poder transferir a cada cliente, la experiencia del proyecto anterior, siempre mejorando nuestro arsenal de herramientas.
Esperemos que el tema comercial no termine -otra vez- convirtiéndonos en simples consumidores. En nuestro medio es muy común "seguir a la manada", usando siglas, abreviaturas, etc. casi como alarde de que supuestamente conocemos un tema. Aquí los "monstruos en computación" usan Firefox, instalan Linux, recompilan Kernels y hasta "hackean" messengers :) pero son contados los que realmente entienden por qué lo hacen, menos aún los que modifican código o crean patchs. Ni qué decir de creaciones propias.
jueves, 11 de febrero de 2010
Mi pesadilla con phpMyAdmin sobre IIS 7
El título puede resultar decepcionante no? Instalar phpMyAdmin es un juego de niños! o al menos siempre ha sido así para mi hasta HOY, pero finalmente luego de más de 5 horas encontré la solución. Y no me tomó mas que apenas 5 segundos.
La receta fatal es esta:
Windows 2008
IIS 7
MySQL 5.0.5
PHP 5.3.1 (FastCGI)
phpMyAdmin 3.2.5
Configuras phpMyAdmin, todo OK. Luego entras al login, luce perfecto, escribes tu login/pass y.... esperas, esperas, esperas una ETERNIDAD hasta que te aparece HTTP Error 500 con el MUY UTIL mensaje "ha ocurrido un error interno" :) Haces de todo, pruebas permisos, versiones, hasta le activas el Trace al IIS, nada de nada.
...pero al final del día, la culpa de todo la tiene el chin... digo... Windows 2008 :)
LA SOLUCIÓN? Probablemente tu config.inc.php incluye "localhost" como nombre de servidor MySQL, pero resulta que en Windows 2008 ese nombre no existe (está comentado en el archivo hosts). No me he tomado la molestia de averiguar por qué aún. Así que con tan sólo cambiarlo por "127.0.0.1", EUREKA! todo funciona de maravillas!
Ojalá esto sirva para salvar a alguien del martirio que tuve hoy.
La receta fatal es esta:
Windows 2008
IIS 7
MySQL 5.0.5
PHP 5.3.1 (FastCGI)
phpMyAdmin 3.2.5
Configuras phpMyAdmin, todo OK. Luego entras al login, luce perfecto, escribes tu login/pass y.... esperas, esperas, esperas una ETERNIDAD hasta que te aparece HTTP Error 500 con el MUY UTIL mensaje "ha ocurrido un error interno" :) Haces de todo, pruebas permisos, versiones, hasta le activas el Trace al IIS, nada de nada.
...pero al final del día, la culpa de todo la tiene el chin... digo... Windows 2008 :)
LA SOLUCIÓN? Probablemente tu config.inc.php incluye "localhost" como nombre de servidor MySQL, pero resulta que en Windows 2008 ese nombre no existe (está comentado en el archivo hosts). No me he tomado la molestia de averiguar por qué aún. Así que con tan sólo cambiarlo por "127.0.0.1", EUREKA! todo funciona de maravillas!
Ojalá esto sirva para salvar a alguien del martirio que tuve hoy.
miércoles, 20 de enero de 2010
FTP Pasivo con Windows 2008
Clásico problema: quiero conectar el Filezilla a uno de nuestros nuevos servidores con Windows 2008 y no funciona como Pasivo, sólo como Activo. Reviso el firewall y tiene una regla para el FTP que obviamente funciona con el modo Activo únicamente.
Luego de buscar un poco por internet encontré estas casi mágicas líneas:
netsh advfirewall firewall add rule name="FTP (no SSL)" action=allow protocol=TCP dir=in localport=21
netsh advfirewall set global StatefulFtp enable
La primera se ocupa del puerto 21 y la segunda del StatefulFtp que aperturará dinámicamente los puertos necesarios para el FTP Pasivo.
Luego de buscar un poco por internet encontré estas casi mágicas líneas:
netsh advfirewall firewall add rule name="FTP (no SSL)" action=allow protocol=TCP dir=in localport=21
netsh advfirewall set global StatefulFtp enable
La primera se ocupa del puerto 21 y la segunda del StatefulFtp que aperturará dinámicamente los puertos necesarios para el FTP Pasivo.
viernes, 24 de julio de 2009
IIS SMTP Service en localhost:25
Ok, quizá sea uno de pocos con tal necesidad porque busqué un buen rato en Google sobre el asunto sin tener éxito.
La cuestión es simple: cómo configurar el SMTP Service del IIS para que sólo responda por el IP 127.0.0.1 (localhost) puerto 25 de modo que podamos tener otro programa en la interface pública, en el mismo puerto, recibiendo los correos que llegan de afuera?
La idea es que el IIS SMTP atienda a las aplicaciones en ASP o PHP que suelen apuntar directamente al localhost:25, dejando libre las interfaces públicas para darles otro uso.
En principio usando el MMC no se puede, porque la dirección 127.0.0.1 no aparece en la lista.
La solución es muy simple: sólo se debe editar la Metabase (generalmente c:\windows\system32\inetsrv\metabase.xml) con notepad o algún otro editor de textos y reiniciar el IIS. Incluso no es necesario reiniciarlo si se tiene activa la opción de poder editar la metabase directamente, ya que en ese caso el IIS detecta que ha sido alterada y la recarga automáticamente sin reiniciar.
Primero, ubicar la línea:
<IIsSmtpServer Location ="xxxxxxxxxxx"
Y desde ese punto buscar:
ServerBindings=":25:"
Lo más probable es que tenga ese valor (":25:") y todo lo que hay que hacer es dejarla así:
ServerBindings="127.0.0.1:25:"
Luego cerramos el editor, cerramos el MMC (si lo teníamos abierto) y si lo reabrimos veremos que la dirección 127.0.0.1 ya aparece como una interface más y por supuesto, ya seleccionada.
Me ha funcionado muy bien. Ahora tengo el IIS SMTP respondiendo sólo por localhost mientras otra aplicación de filtrado de spam recepciona correos entrantes.
UPDATE 12/Feb/2010:
No funciona más. Con Windows 2008 no resulta, parece que internamente la validación es más estricta y por más que pongo el IP del localhost, en el IIS Manager aparece asignado a todas las interfaces. Al final tuve que asignarlo a otro puerto, elegí el 587. En el IP original está el otro servicio SMTP que acepta relaying del localhost, así que funciona bien. Despues de todo el 587 sólo queda para CDONTS o CDO.
La cuestión es simple: cómo configurar el SMTP Service del IIS para que sólo responda por el IP 127.0.0.1 (localhost) puerto 25 de modo que podamos tener otro programa en la interface pública, en el mismo puerto, recibiendo los correos que llegan de afuera?
La idea es que el IIS SMTP atienda a las aplicaciones en ASP o PHP que suelen apuntar directamente al localhost:25, dejando libre las interfaces públicas para darles otro uso.
En principio usando el MMC no se puede, porque la dirección 127.0.0.1 no aparece en la lista.
La solución es muy simple: sólo se debe editar la Metabase (generalmente c:\windows\system32\inetsrv\metabase.xml) con notepad o algún otro editor de textos y reiniciar el IIS. Incluso no es necesario reiniciarlo si se tiene activa la opción de poder editar la metabase directamente, ya que en ese caso el IIS detecta que ha sido alterada y la recarga automáticamente sin reiniciar.
Primero, ubicar la línea:
<IIsSmtpServer Location ="xxxxxxxxxxx"
Y desde ese punto buscar:
ServerBindings=":25:"
Lo más probable es que tenga ese valor (":25:") y todo lo que hay que hacer es dejarla así:
ServerBindings="127.0.0.1:25:"
Luego cerramos el editor, cerramos el MMC (si lo teníamos abierto) y si lo reabrimos veremos que la dirección 127.0.0.1 ya aparece como una interface más y por supuesto, ya seleccionada.
Me ha funcionado muy bien. Ahora tengo el IIS SMTP respondiendo sólo por localhost mientras otra aplicación de filtrado de spam recepciona correos entrantes.
UPDATE 12/Feb/2010:
No funciona más. Con Windows 2008 no resulta, parece que internamente la validación es más estricta y por más que pongo el IP del localhost, en el IIS Manager aparece asignado a todas las interfaces. Al final tuve que asignarlo a otro puerto, elegí el 587. En el IP original está el otro servicio SMTP que acepta relaying del localhost, así que funciona bien. Despues de todo el 587 sólo queda para CDONTS o CDO.
jueves, 9 de julio de 2009
4 días bajo ataque
Desde que empezó esta semana nuestros servidores han estado recibiendo MILES de conexiones SMTP. Al principio fue un gran problema ya que saturaba las conexiones (denegación de servicio) causando que nuestros clientes no pudiesen enviar correos.
Tratamos de analizar la fuente, buscar un patrón, NADA. Totalmente aleatorio. Los IPs cambian todo el tiempo y siempre intentan lo mismo, autenticarse mediante fuerza bruta, probando miles de combinaciones de login/pass. No sabemos si es un virus, spam o algo parecido, al fin y al cabo da lo mismo.
En medio de todas las cosas que tenemos que hacer, tuvimos que hacer espacio para resolver este problema y hemos tenido éxito!
Por suerte el software de correo que empleamos es extremadamente flexible: qmail, vmailmgr, courier-imap, mailfront, mrtg, daemon-tools. Combinados nos han permitido contener el problema en niveles que permiten que nuestros servicios se mantengan operativos.
Empezamos con algunos scripts para ayudarnos a rastrear las fuentes y bloquearlas. Su efecto no duraba mas que unos minutos y de nuevo volvíamos al DoS (Denial of Service). Poco a poco lo fuimos mejorando, hasta que ahora corre cada 5 minutos, analiza los logs, extrae los IPs que dan error de autenticación y los coloca en una lista gris, los compara contra los IPs que sí se han autenticado y los coloca en una lista blanca. Luego procede a bloquear todos los IPs de la lista gris que no estén en la lista blanca. Mantiene un registro de las últimas 24 horas de actividad de modo que los IPs no vuelvan a ser reutilizados en poco tiempo.
A esta hora tenemos bloqueados más de 2000 servidores, de diferentes partes del mundo, principalmente Brasil (famosos por siempre aparecer primeros en las listas de países con servidores zombies).
Hemos investigado en internet si hay "algo" al respecto pero no hemos encontrado nada, no creo que seamos los únicos con este problema!!!
Por ahora, vamos pasando bien la tormenta, van 4 días!!!
Tratamos de analizar la fuente, buscar un patrón, NADA. Totalmente aleatorio. Los IPs cambian todo el tiempo y siempre intentan lo mismo, autenticarse mediante fuerza bruta, probando miles de combinaciones de login/pass. No sabemos si es un virus, spam o algo parecido, al fin y al cabo da lo mismo.
En medio de todas las cosas que tenemos que hacer, tuvimos que hacer espacio para resolver este problema y hemos tenido éxito!
Por suerte el software de correo que empleamos es extremadamente flexible: qmail, vmailmgr, courier-imap, mailfront, mrtg, daemon-tools. Combinados nos han permitido contener el problema en niveles que permiten que nuestros servicios se mantengan operativos.
Empezamos con algunos scripts para ayudarnos a rastrear las fuentes y bloquearlas. Su efecto no duraba mas que unos minutos y de nuevo volvíamos al DoS (Denial of Service). Poco a poco lo fuimos mejorando, hasta que ahora corre cada 5 minutos, analiza los logs, extrae los IPs que dan error de autenticación y los coloca en una lista gris, los compara contra los IPs que sí se han autenticado y los coloca en una lista blanca. Luego procede a bloquear todos los IPs de la lista gris que no estén en la lista blanca. Mantiene un registro de las últimas 24 horas de actividad de modo que los IPs no vuelvan a ser reutilizados en poco tiempo.
A esta hora tenemos bloqueados más de 2000 servidores, de diferentes partes del mundo, principalmente Brasil (famosos por siempre aparecer primeros en las listas de países con servidores zombies).
Hemos investigado en internet si hay "algo" al respecto pero no hemos encontrado nada, no creo que seamos los únicos con este problema!!!
Por ahora, vamos pasando bien la tormenta, van 4 días!!!
miércoles, 6 de mayo de 2009
Spam!
Impresionante: de cada 100 mensajes de correo electrónico en todo el mundo, sólo 2 o 3 son realmente útiles, todo lo demás es SPAM.
Supuestamente deberíamos estar felices porque ha habido una disminución :). Hemos "bajado" de 98.4 en el primer semestre 2008, a "sólo" 97.3. Ya ven? De qué se quejan... el spam va de bajada... :P
Lo cierto es que existe una doble moral en este tema: los usuarios se quejan de que reciben mucho spam pero tambien se quejan cuando sus propios envíos masivos no llegan a destino. En qué quedamos entonces?
"Recibo mucho spam, hagan algo", claro pero envían su lista de precios con la cuenta info@sudominio.com a cientos de personas no interesadas. Obviamente ese mail y ese dominio terminan en las listas de los spammers, que a su vez las venden a otros spammers y... ya se imaginan el final del cuento.
"No llegan mis correos", claro! si la semana pasada enviaron cientos de mails de publicidad (camuflados de boletines) por lo que el dominio e incluso el servidor terminaron en varias listas negras, no pretendan ahora que los demás sigan aceptando sus mails importantísimos de ventas.
El tema del spam es complicado y no me refiero a la parte técnica (que ya de por sí es muy compleja). Existen organizaciones criminales a nivel mundial que están detrás de todo. Son auténticas mafias donde la extorsión e incluso el asesinato son válidos (y no estoy exagerando).
En diversas partes del mundo se hacen intentos por combatir el spam mediante leyes, pero por el carácter global de la internet, es difícil poner controles que realmente funcionen. En Estados Unidos tienen una ley anti-spam muy bonita como adorno, porque para otra cosa no sirve. En el Perú tenemos una ley, que es letra muerta en la práctica. La ley peruana por ejemplo dice que se debe incluir la palabra "Publicidad", pero -hecha la ley, hecha la trampa- los spammers peruanos escriben "Pub1icidad", "Pvblicidad", "Publicida", "P u b l i c i d a d", etc.
Es lógico! no sé quién escribió la ley, pero es evidente que todos trataremos de bloquear todo aquello que diga Publicidad, y los spammers tambien lo saben. Para qué enviar un mail con la bendita palabra que todos bloquearán?
En posteriores posts, pretendo explicar con más detalle la parte técnica del spam.
Supuestamente deberíamos estar felices porque ha habido una disminución :). Hemos "bajado" de 98.4 en el primer semestre 2008, a "sólo" 97.3. Ya ven? De qué se quejan... el spam va de bajada... :P
Lo cierto es que existe una doble moral en este tema: los usuarios se quejan de que reciben mucho spam pero tambien se quejan cuando sus propios envíos masivos no llegan a destino. En qué quedamos entonces?
"Recibo mucho spam, hagan algo", claro pero envían su lista de precios con la cuenta info@sudominio.com a cientos de personas no interesadas. Obviamente ese mail y ese dominio terminan en las listas de los spammers, que a su vez las venden a otros spammers y... ya se imaginan el final del cuento.
"No llegan mis correos", claro! si la semana pasada enviaron cientos de mails de publicidad (camuflados de boletines) por lo que el dominio e incluso el servidor terminaron en varias listas negras, no pretendan ahora que los demás sigan aceptando sus mails importantísimos de ventas.
El tema del spam es complicado y no me refiero a la parte técnica (que ya de por sí es muy compleja). Existen organizaciones criminales a nivel mundial que están detrás de todo. Son auténticas mafias donde la extorsión e incluso el asesinato son válidos (y no estoy exagerando).
En diversas partes del mundo se hacen intentos por combatir el spam mediante leyes, pero por el carácter global de la internet, es difícil poner controles que realmente funcionen. En Estados Unidos tienen una ley anti-spam muy bonita como adorno, porque para otra cosa no sirve. En el Perú tenemos una ley, que es letra muerta en la práctica. La ley peruana por ejemplo dice que se debe incluir la palabra "Publicidad", pero -hecha la ley, hecha la trampa- los spammers peruanos escriben "Pub1icidad", "Pvblicidad", "Publicida", "P u b l i c i d a d", etc.
Es lógico! no sé quién escribió la ley, pero es evidente que todos trataremos de bloquear todo aquello que diga Publicidad, y los spammers tambien lo saben. Para qué enviar un mail con la bendita palabra que todos bloquearán?
En posteriores posts, pretendo explicar con más detalle la parte técnica del spam.
jueves, 9 de abril de 2009
Cuántos bits tiene un byte?
Respuestas: qué es eso, no sé, depende de la resolución, depende de la velocidad de "tu internet", depende del mp3, etc....
Cómo es posible que un profesional que trabaje en desarrollo o actividades relacionadas (diseño, edición, etc.) no sepa algo tan fundamental.
Desde las diferencias entre usar los diferentes formatos gráficos (GIF, JPG, PNG, etc.), pasando por la calidad del audio de un archivo MP3, la velocidad de descarga, el peso de las páginas, la codificación de caracteres (ANSI, UTF, etc), el modelado de bases de datos, la resolución de las pantallas, los colores, etc. etc... (5000 etcs más), TODO parte de bits y bytes.
Si no se entiende algo tan básico, entonces todo lo demás estará construido sobre aire.
--- Un ejemplo ---
Una simple página html. Claro, la página por sí misma no pesa mucho, pero tiene gráficos y según el contenido de cada imagen, uno opta por GIF, JPG o PNG. GIF si los colores son "horizontalmente" planos y pocos, JPG si son fotografías, PNG si no son muy grandes y se necesita transparencia (logotipos, formas, etc.).
GIF admite hasta 256 colores, pero por qué ese número? Porque cada punto se almacena como un byte, que es un número entre 0 y 255 (256 valores posibles).
Por qué? Porque un byte se compone de 8 bits (dígitos binarios) y el máximo número de 8 digitos binarios es 11111111 que equivale a 255.
GIF es ideal para comprimir colores planos porque si un byte se repite N veces, entonces sólo se graba UNA vez el valor y luego se indica cuántas veces se repite. Toda una línea de 1024 pixels del mismo color, se graba en apenas 2 o 3 bytes y no en 1024. La compresión es enorme y la calidad perfecta.
Bueno en realidad es perfecta dependiendo de la cantidad de colores de la imagen, ya que GIF utiliza una paleta, es decir, una selección de hasta 256 de los colores más usados por la imagen. Al almacenar el gráfico no se graba realmente cada color, sino el índice en la paleta al que corresponde dicho color.
Y cómo se graba cada color? Cada color se representa como 3 valores básicos, uno para el rojo, otro para el verde y otro para el azul. Cada color básico tiene 256 posibles variaciones (otra vez ese numerito), por qué? porque cada color se guarda como un byte (de nuevo los 8 bits que permiten almacenar un número entre 0 y 255).
JPG en cambio guarda cada punto directamente como 3 bytes sin usar una paleta, pero utiliza una técnica de compresión por pérdida de calidad. Si cada color se puede expresar como 3 números de 256 posibles valores cada uno, tenemos 256 x 256 x 256 que nos dan los famosos 16 millones de colores (aprox) que admite dicho formato. El ojo humano a duras penas logra distinguir tal gama de colores así que en la práctica no se necesita más.
PNG usa una compresión parecida al GIF así que ya se pueden imaginar que "es pesadito". Además PNG usa un byte adicional para la transparencia (tambien expresada en 256 posibles valores). PNG es útil para formas que deban verse bien, no sean muy grandes y especialmente si requieren transparencia.
--- fin del ejemplo ---
Quizá mareó un poco lo anterior verdad? Pero para realmente lograr que una página pese poco, se deben aplicar correctamente los formatos gráficos, pero si no se sabe algo tan básico como bits y bytes, cómo se podrá comprender lo anterior?
Lo mismo se aplica a los caracteres ASCII, ANSI, UTF8, etc.
Sabían que cuando mandan un attachment por mail, durante la transmisión mide 30% más aprox? Por qué? porque se debe expresar los bytes del archivo como caracteres estándar dentro del mail (que sólo admite 7 bits), así que algunos valores deben expresarse en varios bytes.
...y así podría dar N ejemplos, en otro momento quizá profundice sobre los formatos gráficos o por qué alguien caprichosamente quizo usar 8 bits y no 10, 5 o 1 (o quizá no fue un capricho? todo tiene su explicación), por ahora sólo he querido mostrar la importancia de algo tan elemental en el trabajo diario de un desarrollador, diseñador, etc.
Pueden empezar por Wikipedia: BIT y ya si son "atrevidos" lean sobre numeración hexadecimal.
Qué se diviertan :)
Cómo es posible que un profesional que trabaje en desarrollo o actividades relacionadas (diseño, edición, etc.) no sepa algo tan fundamental.
Desde las diferencias entre usar los diferentes formatos gráficos (GIF, JPG, PNG, etc.), pasando por la calidad del audio de un archivo MP3, la velocidad de descarga, el peso de las páginas, la codificación de caracteres (ANSI, UTF, etc), el modelado de bases de datos, la resolución de las pantallas, los colores, etc. etc... (5000 etcs más), TODO parte de bits y bytes.
Si no se entiende algo tan básico, entonces todo lo demás estará construido sobre aire.
--- Un ejemplo ---
Una simple página html. Claro, la página por sí misma no pesa mucho, pero tiene gráficos y según el contenido de cada imagen, uno opta por GIF, JPG o PNG. GIF si los colores son "horizontalmente" planos y pocos, JPG si son fotografías, PNG si no son muy grandes y se necesita transparencia (logotipos, formas, etc.).
GIF admite hasta 256 colores, pero por qué ese número? Porque cada punto se almacena como un byte, que es un número entre 0 y 255 (256 valores posibles).
Por qué? Porque un byte se compone de 8 bits (dígitos binarios) y el máximo número de 8 digitos binarios es 11111111 que equivale a 255.
GIF es ideal para comprimir colores planos porque si un byte se repite N veces, entonces sólo se graba UNA vez el valor y luego se indica cuántas veces se repite. Toda una línea de 1024 pixels del mismo color, se graba en apenas 2 o 3 bytes y no en 1024. La compresión es enorme y la calidad perfecta.
Bueno en realidad es perfecta dependiendo de la cantidad de colores de la imagen, ya que GIF utiliza una paleta, es decir, una selección de hasta 256 de los colores más usados por la imagen. Al almacenar el gráfico no se graba realmente cada color, sino el índice en la paleta al que corresponde dicho color.
Y cómo se graba cada color? Cada color se representa como 3 valores básicos, uno para el rojo, otro para el verde y otro para el azul. Cada color básico tiene 256 posibles variaciones (otra vez ese numerito), por qué? porque cada color se guarda como un byte (de nuevo los 8 bits que permiten almacenar un número entre 0 y 255).
JPG en cambio guarda cada punto directamente como 3 bytes sin usar una paleta, pero utiliza una técnica de compresión por pérdida de calidad. Si cada color se puede expresar como 3 números de 256 posibles valores cada uno, tenemos 256 x 256 x 256 que nos dan los famosos 16 millones de colores (aprox) que admite dicho formato. El ojo humano a duras penas logra distinguir tal gama de colores así que en la práctica no se necesita más.
PNG usa una compresión parecida al GIF así que ya se pueden imaginar que "es pesadito". Además PNG usa un byte adicional para la transparencia (tambien expresada en 256 posibles valores). PNG es útil para formas que deban verse bien, no sean muy grandes y especialmente si requieren transparencia.
--- fin del ejemplo ---
Quizá mareó un poco lo anterior verdad? Pero para realmente lograr que una página pese poco, se deben aplicar correctamente los formatos gráficos, pero si no se sabe algo tan básico como bits y bytes, cómo se podrá comprender lo anterior?
Lo mismo se aplica a los caracteres ASCII, ANSI, UTF8, etc.
Sabían que cuando mandan un attachment por mail, durante la transmisión mide 30% más aprox? Por qué? porque se debe expresar los bytes del archivo como caracteres estándar dentro del mail (que sólo admite 7 bits), así que algunos valores deben expresarse en varios bytes.
...y así podría dar N ejemplos, en otro momento quizá profundice sobre los formatos gráficos o por qué alguien caprichosamente quizo usar 8 bits y no 10, 5 o 1 (o quizá no fue un capricho? todo tiene su explicación), por ahora sólo he querido mostrar la importancia de algo tan elemental en el trabajo diario de un desarrollador, diseñador, etc.
Pueden empezar por Wikipedia: BIT y ya si son "atrevidos" lean sobre numeración hexadecimal.
Qué se diviertan :)
El código es tu amigo
He hecho reir a muchos con esta frase, pero su significado oculto no es para reirse.
El software libre es algo muy bueno pero está causando -al menos en mi país: Perú- un efecto secundario muy peligroso. Los nuevos "profesionales" ya no quieren programar, sólo buscan copiar y adaptar lo que ya existe.
Así pues el panorama de soluciones se está volviendo bastante aburrido: Joomla, Drupal, Moodle, etc.
Por último estas aplicaciones son personalizables, pero ni eso quieren hacer. Es decir, en lugar de crear un estilo (css) único, recurren a plantillas!
Le tienen pánico al código? Tienen la más mínima idea de cómo crear una simple rutina recursiva para calcular el factorial de un número? Nooo, pero es común escucharlos hablar como expertos respecto a las aplicaciones antes mencionadas. "Saber Joomla" (!!!????). Hasta hace algún tiempo los que sabían C++ o Java eran los expertos mientras que los que usaban scripts (ASP, PHP, etc.) eran los "apurados" o menos expertos (por ser suave). Ahora ya ni eso!
Existe tal cantidad de scripts en internet y mucha gente simplemente los baja aún sin entenderlos del todo. Si sabes "instalarlos" ya "sabes".
Señores: el código es su amigo, un verdadero profesional no tiene reparos en utilizar Notepad (o incluso "vi" en Linux). Piérdanle el miedo, la prueba de fuego es crear un web simple sin más herramientas que un editor de texto simple:
Una página HTML, su respectiva hoja de estilos, un archivo externo de código javascript y con eso tendremos un buen comienzo. Luego algo de código en PHP (o similar), quizá un poco de XML y habremos comprendido muchísimo más. Luego pueden volver a sus herramientas habituales (Dreamweaver no? Si pues, otro caso de herramienta que "los que saben, deben usar"). El haberlo hecho a mano algunas veces les ayudará muchísimo a entender los principios básicos, por qué aparecen errores inexplicables, por qué es mejor hacer las cosas de tal o cual forma. Creanme que con el tiempo, les parecerá una pérdida de tiempo usar editores y si son enfermizamente perfeccionistas como yo, entonces nunca más instalarán otra cosa que no sea un mejor editor "de texto" (mi favorito: Notepad++)
Lo mismo con el código copiado. Intenten entenderlo, no lo peguen por pegar. Pueden estar introduciendo un riesgo de seguridad. Además puede que pierdan algo de tiempo la primera vez, pero luego, cuando vuelvan a estar ante una situación similar, podrán aplicar la solución muy rápidamente y adaptarla. Mejor aún si crean su propio código!
Hace algunas semanas me topé con una solución de una pequeña empresa norteamericana que querían desplegar usando nuestro servicio de hosting. La aplicación web estaba construida nada más y nada menos que en C++! construida con CGIs, pero usando plantillas, con separación de código y todo. Me gusto la simpleza y elegancia de su solución. Quizá sea algo extremo usar C++ para una aplicación web en estos tiempos, pero fue bueno ver algo distinto a lo común de estos días.
En VIS tenemos una política: el código tiene que ser nuestro, evitamos en lo posible usar librerías o rutinas de otros. Sólo así podemos garantizar que nuestras soluciones funcionarán como nosotros queremos. Desde nuestra propia plataforma (CMS), nuestros propios módulos, librerías, etc. Salvo necesidades muy puntuales o demasiado especializadas, todo el código es nuestro y lo comprendemos a la perfección.
...porque si seguimos así, dejaremos de tener desarrolladores y pasaremos a ser simplemente "copiones" de lo que otros crean. Y así, cómo evolucionaremos? Seremos más dependientes que nunca!
Señores, programen! dejen de copiar!
El software libre es algo muy bueno pero está causando -al menos en mi país: Perú- un efecto secundario muy peligroso. Los nuevos "profesionales" ya no quieren programar, sólo buscan copiar y adaptar lo que ya existe.
Así pues el panorama de soluciones se está volviendo bastante aburrido: Joomla, Drupal, Moodle, etc.
Por último estas aplicaciones son personalizables, pero ni eso quieren hacer. Es decir, en lugar de crear un estilo (css) único, recurren a plantillas!
Le tienen pánico al código? Tienen la más mínima idea de cómo crear una simple rutina recursiva para calcular el factorial de un número? Nooo, pero es común escucharlos hablar como expertos respecto a las aplicaciones antes mencionadas. "Saber Joomla" (!!!????). Hasta hace algún tiempo los que sabían C++ o Java eran los expertos mientras que los que usaban scripts (ASP, PHP, etc.) eran los "apurados" o menos expertos (por ser suave). Ahora ya ni eso!
Existe tal cantidad de scripts en internet y mucha gente simplemente los baja aún sin entenderlos del todo. Si sabes "instalarlos" ya "sabes".
Señores: el código es su amigo, un verdadero profesional no tiene reparos en utilizar Notepad (o incluso "vi" en Linux). Piérdanle el miedo, la prueba de fuego es crear un web simple sin más herramientas que un editor de texto simple:
Una página HTML, su respectiva hoja de estilos, un archivo externo de código javascript y con eso tendremos un buen comienzo. Luego algo de código en PHP (o similar), quizá un poco de XML y habremos comprendido muchísimo más. Luego pueden volver a sus herramientas habituales (Dreamweaver no? Si pues, otro caso de herramienta que "los que saben, deben usar"). El haberlo hecho a mano algunas veces les ayudará muchísimo a entender los principios básicos, por qué aparecen errores inexplicables, por qué es mejor hacer las cosas de tal o cual forma. Creanme que con el tiempo, les parecerá una pérdida de tiempo usar editores y si son enfermizamente perfeccionistas como yo, entonces nunca más instalarán otra cosa que no sea un mejor editor "de texto" (mi favorito: Notepad++)
Lo mismo con el código copiado. Intenten entenderlo, no lo peguen por pegar. Pueden estar introduciendo un riesgo de seguridad. Además puede que pierdan algo de tiempo la primera vez, pero luego, cuando vuelvan a estar ante una situación similar, podrán aplicar la solución muy rápidamente y adaptarla. Mejor aún si crean su propio código!
Hace algunas semanas me topé con una solución de una pequeña empresa norteamericana que querían desplegar usando nuestro servicio de hosting. La aplicación web estaba construida nada más y nada menos que en C++! construida con CGIs, pero usando plantillas, con separación de código y todo. Me gusto la simpleza y elegancia de su solución. Quizá sea algo extremo usar C++ para una aplicación web en estos tiempos, pero fue bueno ver algo distinto a lo común de estos días.
En VIS tenemos una política: el código tiene que ser nuestro, evitamos en lo posible usar librerías o rutinas de otros. Sólo así podemos garantizar que nuestras soluciones funcionarán como nosotros queremos. Desde nuestra propia plataforma (CMS), nuestros propios módulos, librerías, etc. Salvo necesidades muy puntuales o demasiado especializadas, todo el código es nuestro y lo comprendemos a la perfección.
...porque si seguimos así, dejaremos de tener desarrolladores y pasaremos a ser simplemente "copiones" de lo que otros crean. Y así, cómo evolucionaremos? Seremos más dependientes que nunca!
Señores, programen! dejen de copiar!
Chrome!
En los últimos años ha habido un cambio drástico en los navegadores de internet. Nosotros en VIS hemos vivido casi toda la historia, desde aquellos días en que Netscape era el navegador dominante.
Qué complicado era al principio! Los webs tenían que ser extremadamente simples, para evitar problemas con aquellos que no soportaban tablas o que no ejecutaban javascript (sí... hace mucho, mucho tiempo). Aún recuerdo la "promesa" Java, que nunca terminó por imponerse, recuerdo la primera vez que ví una animación vectorial en web y luego de investigar descubrí que era Flash! pero estaba en pañales y sin embargo, logró lo que Java no consiguió! (al menos en el entorno web).
Internet Explorer
La verdadera revolución vino con Internet Explorer 4: muy criticado, lento, lleno de bugs, etc. pero -aunque algunos se rasguen las vestiduras por mi comentario- el mejor de entonces. El hecho de que cualquier elemento HTML pudiera ser modificado, más la semilla del Ajax que ya llevaba, permitían todo un nuevo abanico de posibilidades.
Las controversiales medidas de Microsoft causaron su masificación (vencedor de la primera guerra de browsers) y la virtual inexistencia (en la práctica) de estándares, ocasionó que los sitios web se orientaran principalmente a este navegador. Y era una cuestión matemática, bastaba ver las estadísticas de cualquier sitio web y ante más del 95% de utilización de Internet Explorer, resultaba casi absurdo desperdiciar recursos y agregar limitaciones por aquel otro porcentaje mínimo. Más que un tema técnico, era un tema de costo-beneficio.
Y asi durante muchos años el "estándar" de facto era la orientación del código hacia Internet Explorer.
Aún recuerdo el trabajo enorme que nos costó que LaNet (un antiguo proyecto nuestro de finales de los 90) pudiera operar en Explorer y Netscape "casi" sin problemas. En gran parte gracias a Java (Flash aún era una curiosidad rara, muy muy rara).
Firefox
Confieso que nunca he sido precisamente un fan de Firefox, principalmente porque debido a mi trabajo tenía que preocuparme del porcentaje mayoritario de personas que usarían nuestras creaciones. Incluso llegamos a darle más importancia a Safari, debido a que otra de nuestras creaciones -Caretas-, era muy usada en Macs. Fue muy problemático garantizar que funcionara bien con Safari, porque no teníamos uno. Tuvimos que usar un Linux virtual (VMWare) ejecutando Konqueror (la base de Safari) para "acercarnos" lo más posible (mucho despues llegaría la versión Windows de Safari).
Finalmente, las estadísticas empezaron a cambiar: de pronto Internet Explorer perdía terreno, Firefox subía respetablemente, Safari ya no aparecía en "otros", etc. Luego vendría el iPhone y todos los celulares con navegadores, etc. Los estándares finalmente habían madurado.
...y apareció Chrome!
Me rindo ante su sencillez, limpieza y velocidad. En apenas horas hizo lo que Firefox nunca pudo: arrancarme de Internet Explorer. Cuál es mejor? No hay que complicarse la vida, es una mera cuestión de gustos! A mi en particular nunca me ha gustado usar un producto simplemente "para parecer que sé" del tema, algo que he notado con Firefox. Es como un sello distintivo: si usas Firefox es porque "sabes", de lo contrario eres un Lamer :) bueno, a mi me gusta Chrome! lo siento mucho.
Su forma de manejar la memoria, priorizando seguridad e independencia y no tanto ahorro (o quizá otra forma de ahorro?), su motor de javascript mucho más rapido que los otros, su interface tan limpia y sin miles de opciones, en resumen: ese estilo "minimalista", terminaron en conjunto por gustarme mucho.
Claro que son otros tiempos: con los estándares tan masificados hoy hacemos las pruebas con IE 6, 7 y 8, Firefox, Safari y Chrome (además de nuestros celulares con Windows Mobile, en mi caso ejecutando NetFront). En esta nueva realidad, el problemático casi siempre resulta siendo IE, pero nada que una hoja CSS secundaria (de 3 o 4 líneas) no pueda resolver.
Qué complicado era al principio! Los webs tenían que ser extremadamente simples, para evitar problemas con aquellos que no soportaban tablas o que no ejecutaban javascript (sí... hace mucho, mucho tiempo). Aún recuerdo la "promesa" Java, que nunca terminó por imponerse, recuerdo la primera vez que ví una animación vectorial en web y luego de investigar descubrí que era Flash! pero estaba en pañales y sin embargo, logró lo que Java no consiguió! (al menos en el entorno web).
Internet Explorer
La verdadera revolución vino con Internet Explorer 4: muy criticado, lento, lleno de bugs, etc. pero -aunque algunos se rasguen las vestiduras por mi comentario- el mejor de entonces. El hecho de que cualquier elemento HTML pudiera ser modificado, más la semilla del Ajax que ya llevaba, permitían todo un nuevo abanico de posibilidades.
Las controversiales medidas de Microsoft causaron su masificación (vencedor de la primera guerra de browsers) y la virtual inexistencia (en la práctica) de estándares, ocasionó que los sitios web se orientaran principalmente a este navegador. Y era una cuestión matemática, bastaba ver las estadísticas de cualquier sitio web y ante más del 95% de utilización de Internet Explorer, resultaba casi absurdo desperdiciar recursos y agregar limitaciones por aquel otro porcentaje mínimo. Más que un tema técnico, era un tema de costo-beneficio.
Y asi durante muchos años el "estándar" de facto era la orientación del código hacia Internet Explorer.
Aún recuerdo el trabajo enorme que nos costó que LaNet (un antiguo proyecto nuestro de finales de los 90) pudiera operar en Explorer y Netscape "casi" sin problemas. En gran parte gracias a Java (Flash aún era una curiosidad rara, muy muy rara).
Firefox
Confieso que nunca he sido precisamente un fan de Firefox, principalmente porque debido a mi trabajo tenía que preocuparme del porcentaje mayoritario de personas que usarían nuestras creaciones. Incluso llegamos a darle más importancia a Safari, debido a que otra de nuestras creaciones -Caretas-, era muy usada en Macs. Fue muy problemático garantizar que funcionara bien con Safari, porque no teníamos uno. Tuvimos que usar un Linux virtual (VMWare) ejecutando Konqueror (la base de Safari) para "acercarnos" lo más posible (mucho despues llegaría la versión Windows de Safari).
Finalmente, las estadísticas empezaron a cambiar: de pronto Internet Explorer perdía terreno, Firefox subía respetablemente, Safari ya no aparecía en "otros", etc. Luego vendría el iPhone y todos los celulares con navegadores, etc. Los estándares finalmente habían madurado.
...y apareció Chrome!
Me rindo ante su sencillez, limpieza y velocidad. En apenas horas hizo lo que Firefox nunca pudo: arrancarme de Internet Explorer. Cuál es mejor? No hay que complicarse la vida, es una mera cuestión de gustos! A mi en particular nunca me ha gustado usar un producto simplemente "para parecer que sé" del tema, algo que he notado con Firefox. Es como un sello distintivo: si usas Firefox es porque "sabes", de lo contrario eres un Lamer :) bueno, a mi me gusta Chrome! lo siento mucho.
Su forma de manejar la memoria, priorizando seguridad e independencia y no tanto ahorro (o quizá otra forma de ahorro?), su motor de javascript mucho más rapido que los otros, su interface tan limpia y sin miles de opciones, en resumen: ese estilo "minimalista", terminaron en conjunto por gustarme mucho.
Claro que son otros tiempos: con los estándares tan masificados hoy hacemos las pruebas con IE 6, 7 y 8, Firefox, Safari y Chrome (además de nuestros celulares con Windows Mobile, en mi caso ejecutando NetFront). En esta nueva realidad, el problemático casi siempre resulta siendo IE, pero nada que una hoja CSS secundaria (de 3 o 4 líneas) no pueda resolver.
Suscribirse a:
Entradas (Atom)
.jpg)
