Cambios Técnicos no documentados en Red Hat Linux 9
Cambios
Técnicos no documentados en Red Hat Linux 9
(o lo
que las notas de liberación no contaron)
por Dax.Kelson@GuruLabs.com
Copyright 2003 Guru Labs, L.C.
Nota: Si sabes de algún cambio nuevo
indocumentado de RH90 que no tomé en cuenta, por favor házmelo saber.
Traducido por Dardo
A. Valdez
Introducción
En los pasados 8 años o más, me emocioné con la liberación de cada
nueva version de Red Hat Linux. Durante los últimos años, mucha gente ha
escrito revisiones acerca de cada una de ellas, teniendo como regla
general, al parecer, analizar cosas superficiales, errores menores, e
irrelevantes detalles; a veces incluso, estas revisiones eran realizadas
por personas que no tenían un conocimiento íntimo sobre sistemas Red
Hat.
Un administrador de sistemas necesitaría que una revision adecuada
cubriera en profundidad los siguientes temas, desde el punto de vista
comparativo con la versión anterior:
-
Cambios de Arquitectura y
comportamiento en general -
Cambios en la Instalación
-
Cambios en los paquetes incluídos
Normalmente, con cada nueva versión de Red Hat Linux , alguien en
Guru Labs la revisa en profundidad buscando lo que ha cambiado para
actualizar los cursos de Linux que tenemos. Esta vez fue mi turno, y
decidí escribir una revision y un análisis técnico para administradores
de sistemas de manera simultánea. Espero que el resultado sea
satisfactorio para el lector.
Notas de Abreviación:
RHL = Red Hat Linux
RH = Red Hat Inc.
Cambios de Arquitectura y comportamiento en general
Hubieron muchos cambios entre las versiones RHL7.3 y la 8.0, por
ejemplo, el uso de root=LABEL=/
en el archivo /boot/grub/grub.conf
, el reemplazo del programa Xconfigurator
con el redhat-config-xfree86
y el nuevo demonio de clientes DHCP, dhclient que evita el uso
de interfaces que no están enlazadas. Aparentemente no hay cambios tan
radicales entre RHL8.0 y RHL9, pero las apariencias suelen engañar, y
bajo la superficie de la distribución encontramos significativas
modificaciones.
Kernel 2.4.20-8
El kernel incluído en RH8.0 estaba basado en el código del kernel
2.4.18. En RH9, a pesar del nombre, el kernel 2.4.20-8 está basado en el
2.4.20 más bugfixes incluídos hasta el 2.4.21-pre4-ac4. Durante los
últimos años, los kernels de RH han incluído funcionalidad portada de
las versiones en desarrollo del kernel, que ya se ha probado, son
aceptablemente estables. El nuevo kernel de RH9 no es la excepción. Los
mayores cambios desde RH8.0 son:
-
La adición de la Native POSIX
Thread Library (NPTL)
para soportar hilos de manera estándarizada con muy buen rendimiento.
Esto es definitivamente un buen agregado, pero les anticipo que
aquellos administradores de sistemas que quieran añadir parches de
terceros a los fuentes de este kernel (como por ejemplo: UML, FreeSWAN,
etc.), tendrán dificultades para aplicarlos limpiamente.Presumiblemente con la liberación
del kernel 2.6, los kernels modificados de RHL disminuirán sus
apariciones en las versiones oficiales.-
Ciertas aplicaciones que usan la
vieja API de threads (hilos), de Linux de cierto modo particular,
puede que no funcionen con este kernel.-
En particular si usa Java,
actualizate a la última version de Sun en: -
La API WIN32 de WINE,
también sufre este inconveniente. Los arreglos para esto ya están
siendo codificados, pero por ahora existe una
solución alternativa. -
Instalar y
ejecutar Oracle 9i R2 tiene cuestiones más importantes a resolver
ya que incluye embebidas dos diferentes versiones viejas de JVMs
(Java Virtual Machine), que no funcionan con NPTL. La solución es
usar la versión para RH8.0 o la edición oficialmente soportada Red
Hat Linux AS.
-
-
-
El soporte ACPI apareció en las
versiones beta (al igual que en las de RH8.0), pero, fue
removido en la versión final del kernel incluído. -
El soporte para sistemas de archivo ACL y EA apareció en las versiones
beta, pero fue descartado para la version final. Era muy esperada esta
característica en RHL (Solaris tiene soporte desde la versión 2.5.1),
tal vez en algún kernel de actualización reaparezca.-
Para ver que software
específicamente soporta ACLs y EAs (más allá de setfacl/getfacl/setfattr/getfattr),
ejecute: -
rpm -e --test libacl y rpm -e --test libattr
-
Una observación rápida. La
manera en que los editores de texto guardan los archivos normalmente
es creando un nuevo archivo temporal con un nombre genérico (el
clásico \'buffer\' de emacs), y luego lo mueven/renombran dándole el
nombre del archivo original. El uso de esta técnica si el archivo que
está siendo editado tiene ACLs, provocará la pérdida de ellas. El
editor Vim usa la librería libacl para obtener las ACLs
originales, y luego las añade al guardar el archivo. Es importante
actualizar otras aplicaciones que guarden archivos con la misma
técnica, para que usen libacl.
-
-
-
El kernel de RHL 8.0 incluía el
User Mode Linux (UML)
para ejecutar \'Linux en Linux\' (de manera similar a VMware pero sin
el hardware virtual). Debido a las dificultades para parchear (según
lo que ya comenté), el nuevo kernel no incluye UML. Ya que UML es
ahora parte oficial del kernel de desarrollo 2.5 , es de esperar que se
incluya cuando RH utilice la version 2.6. -
Nvidia liberó recientemente nuevos drivers
compatibles con el kernel de RHL9. -
En esta versión de RHL9, para los que usan el muy popular
hardware Wavelan IEEE wireless ethernet 802.11b, el driver por defecto
ha sido actualizado de el
viejo wvlan_cs al driver orinoco_cs. Mi laptop tiene esta placa
on-board, y funciona muy bien hasta con 4 access points que le
conecté con y sin WEP.
XFree86 4.3.0-2
Red Hat Linux 9 viene con el ansiosamente esperado XFree86 4.3 que
incluye muchos drivers
actualizados y nuevas
características. Los adminstradores de sistemas se alegrarán de que
ahora podrán deshabilitar el cambio a las terminales con el clásico
CTL-ALT-Tecla de Función. Esto se vuelve muy útil cuando se deshabilita
también la combinación CTL-ALT-BKSP (que permiter forzar la terminación
y cierre del servidor X), lo que se hace cuando se usa el sistema en
modo \'kiosko\' por ejemplo. Para hacerlo edite /etc/X11/XF86Config y
añada lo siguiente:
Section ServerFlags
# previene el uso de CTL-ALT-F1, etc
Option DontVTSwitch On
#
previene el uso de CTL-ALT-BKSP
Option DontZap On
EndSection
Para el usuario final hay varios cambios visibles, XFree86 tiene ahora
la extensión Xcursor extension que permite el uso de temas (\'themes\'),
de cursor con soporte de animación y transparencias. Red Hat creó un
tema de cursor por defecto atractivo y de muy buen aspecto. Imagino que
no pasará mucho tiempo antes de que los que se dedican a crear temas
para escritorios incluyan cursores como parte de ellos. Mientras esto
sucede, puedes usar la gran colección
de temas de cursor CursorXP de
Stardock, convirtiendolos al formato usado por X con el script sd2xc.pl
Lee el artículo de Nicholas Petreley\'s Adding eye
candy to your desktop (“Añadiendo encanto gráfico al escritorio”),
para más información.
Un muy buen agregado para XFree86 es la posibilidad de cambiar la
resolución de la pantalla \'al vuelo\' (como lo hace Windows). Esto se
hace posible en la version XFree86 4.3 gracias al trabajo de Keith
Packard y otros en la extensión Xrandr (X Resize, Rotate and Reflection
– Redimensionado, Rotación y Reflexión de X). Un nuevo comando, xrandr, es el que
permite hacerlo desde la línea de comando. Para los fanáticos del
\'apuntar y clickear\', programas integrados en las GUI de KDE y GNOME
están en desarrollo. El comando xrandr tiene un uso muy
directo: para mostrar las resoluciones posibles use la opción -q , y para cambiar la
resolución -s
option. Por ejemplo:
[dkelson@mentor dkelson]$ xrandr
-q
SZ:
Pixels
Physical Refresh
*0 1400 x
1050 ( 474mm x 356mm ) *60
1 1280 x
1024 ( 474mm x 356mm ) 60
2 1280 x
960 ( 474mm x 356mm ) 60
3 1152 x
864 ( 474mm x 356mm ) 60
4 1024 x
768 ( 474mm x 356mm ) 60
5
800 x 600 ( 474mm x 356mm ) 60
6
640 x 480 ( 474mm x 356mm ) 60
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none
[dkelson@mentor dkelson]$ xrandr -s 4
Finalmente, el driver de código abierto para las ATI Radeon 3D tuvo una
actualización. El mismo ahora soporta TCL por hardware para mejor
rendimiento 3D y compatibilidad con las últimas aplicaciones de este
tipo (Maya por ejemplo o los más lúdicos salvapantallas REALLY SLICK que ahora
funcionan sin problemas :-) Puedes bajar un paquete rpm para Red
Hat Linux 9 de la página
de downloads de Gurú Labs.
Cambios en el área de Redes
Red Hat Linux siempre guardó los seteos de la configuración de red
en el conjunto de archivos y directorios bajo /etc/sysconfig/. Las
placas de red se configuran en el archivo /etc/sysconfig/network-scripts/ifcfg-nombre_de_la_placa_de_red
. Esto puede hacerse manualmente o via frontends como redhat-config-network (el
comando de versiones anteriores era \'neat\'), o con el
frontend de modo texto (interfaz curses) netconfig. Las
diferencias entre estos son substanciales: por ejemplo, netconfig no puede
configurar conexiones PPP y Wireless mientras que redhat-config-network sí
lo hace. Configurar PPP en Red Hat Linux a mano implica editar y crear
muchos diferentes archivos de texto. La vida es corta y si bien pienso
que soy capaz de setear a mano PPP, prefiero usar redhat-config-network.
Esto siempre ha implicado estar en X, hasta ahora, ya que Red Hat Linux
9, dispone de una interfaz modo texto , redhat-config-network-tui.
Otros cambios en el aspecto de redes a continuación:
Soporte de 801.1q VLAN en los archivos de
configuración
Hay dos estándares principales para crear VLANs
con switches ethernet: el estándar basado en 802.1q, y el
propietario ISL de Cisco. Desde el kernel 2.4.14, el soporte para 802.1q
VLAN está incluído en la versión oficial. Para el sistema, una VLAN se
ve simplemente como una interfaz de red normal. Desde un muy
actualizado Red Hat Linux 7.1 hasta la versión 8.0 de Red Hat tienen el
soporte necesario; sin embargo para configurar VLANs se necesita el
comando vconfig que
no está incluído en ninguna de esas versiones de RHL, incluso tampoco
estaba definido un modo estandarizado de definir configuraciones VLAN en
los archivos de configuración de red estándar de RHL. RHL 9 incluye el
RPM vconfig, e implementa un método \'oficial\' de configuración de
archivos para definir VLANs.
Es importante notar que RHL9 usa modo de nombrar DEV_PLUS_VID_NO_PAD,
lo que significa que el nombre de la interfaz de red de la VLAN
comenzará con el nombre de la placa en sí seguido de un punto y luego el
número de la VLAN. Por ejemplo la interfaz eth2.101 sería VLAN 101 en eth2.
El archivo de configuración de la interfaz, para el ejemplo de
arriba sería: /etc/sysconfig/network-scripts/ifcfg-eth2.101
y contendría las entradas estándar dentro de él.
Lo último que voy a mencionar es que ciertas placas y drivers placas de
red pueden tener problemas con frames ethernet grandes (el encabezado
VLAN incrementa el tamaño de cabecera) Comentario aparte, he tenido un
buen desempeño con la placa Intel PRO1000 MT Desktop Adapter usando el
driver por defecto e1000. Esta placa se puede comprar por menos de U$S
50 en la Red.
Cambios en las interfaces de Reded Virtuales
Interfaces virtuales como ifcfg-eth0:1 no respetaban el ONBOOT=no, y eran
siempre \'levantadas\' con su interfaz \'padre\'. Ahora, haciendo una
\"corrección\" (para algo que debería haber funcionado desde el
principio), RHL9 sorprenderá a muchos administradores de sistema que sin
saberlo tienen el ONBOOT=no
sus archivos ya que ahora efectivamente funciona. Para los
administradores que no quieran ser sorprendidos, un cambio de
compatibilidad hacia atrás se ha hecho y ahora añadiendo ONPARENT=no al archivo ifcfg-ethX:Y, ésta no
será \'levanta\' junto con su \'padre\'.
Cambio en el archivo de configuración de ruteos
estáticos (Static Route)
Historicamente definir ruteos estáticos en RHL involucraba añadir
las entradas de texto apropiadas al archivo /etc/sysconfig/static-routes.
En RHL8.0 esto mayormente no funcionaba. En RHL9 el archivo /etc/sysconfig/static-routes ya no se usa; ahora hay un
archivo separado para cada interfaz destinado a la definición de rutas
estáticas. Los nombres de archivo son:
/etc/sysconfig/network-scripts/route-interfacename
Cada línea debe tener los argumentos que son pasados al comando \"/sbin/ip route add\" por ejemplo:
198.168.2.0/24 via
10.2.3.200
Para rutas estáticas Ipv6, los nombres de archivo son:
/etc/sysconfig/network-scripts/route6-interfacename
Cambios en IPv6
Direcciones secundarias Ipv6 ahora también son configurables sobre
interfaces túnel.
El Very Secure FTP Daemon (vsftpd) corre ahora como
standalone
En RHL8.0 vsftpd era ejecutado desde Xinetd; en RHL9 corre solo
(standalone), y tiene su consecuente script de inicio SysV. El
Washington University FTP Daemon (wu-ftpd) no está incluído en RHL9. Si
usabas wu-ftpd, migra tu configuración a vsftpd.
El comando ifup y perfiles
Es un hecho el que la nueva versión de RHL soporta múltiples
perfiles de red. Esto es útil para máquinas que se conectan a diferentes
redes (como las portátiles). La manera fácil de crear perfiles de red es
usar el comando redhat-config-network
. La pregunta que aparece luego: que pasa si tipeo \"ifup eth0\"? El
comportamiento para ese caso no estaba definido en versiones anteriores,
pero en RHL9, sí lo está;
search path for:
# ifup $DEV
is:
/etc/sysconfig/networking/profiles/$CURRENT_PROFILE/ifcfg-$DEV
/etc/sysconfig/networking/profiles/default/ifcfg-$DEV
/etc/sysconfig/network-scripts/ifcfg-$DEV
Un buen truco es bootear tu máquina RHL en cierto perfil
directamente desde el booteador GRUB. Para hacerlo, crea una nueva
entrada en /etc/boot/grub.conf
para cada perfil de red quieras habilitar pasando al kernel el argumento netprofile=profilename.
Dirección \'scope\' configurable en interfaces de red
Los archivos ifcfg-interfacename,
el ítem de configuración SCOPE puede setearse ahora a valores
absolutos. Esto puede ser útil (entre otras cosas), en la
selección fina de direcciones de origen para conexiones de originadas
desde la misma máquina.
IPTables 1.2.7a
La versión incluída en RHL9 de IPTables es la 1.2.7a versus la
1.2.6a de RHL8.0. No hay muchos cambios, aunque los que usen Servicios
Diferenciados (Differentiated Services), ECN o Ipv6, quedarán
satisfechos.Vea la lista completa de cambios aquí.
El módulo de PHP se configura en archivos separados
El popular PHP no ha cambiados de versión (4.2.2)
de RHL8.0 a RHL9, pero sí ha ocurrido un cambio en la manera de
configurarlo. El archivo principal de configuración de PHP es como
siempre /etc/php.ini,
pero en RHL9 existe un directorio /etc/php.d/. El lenguaje
PHP es extensible por medio de módulos, y los más importantes en RHL.
(snmp,pgsql,ldap,mysql,odbc,imap), han sido separados en distintos
paquetes RPMs. En RHL9 los archivos principales de configuración van
todos a /etc/php.d/,
y los módulos ubican allí sus archivos de configuración. Este es el
mismo tipo de cambio que se hizo a Apache en RHL8.0, en el que se separó
a los archivos de configuración de los módulos guardados en /etc/httpd/conf.d/.
RPMs Debuginfo
Cuando creamos RPMs usando rpmbuild -ba specfile
o rpmbuild --rebuild
foo.src.rpm, un RPM debuginfo es automáticamente construído
junto con el RPM \'normal\'. Esto puede ser útil cuando la
aplicación se cuelga y queremos tener una idea de por qué, para esto
debemos instalar el paquete debuginfo también. Para más información vea
las NOTAS
DE LIBERACIÓN y la propuesta
inicial de la idea.
Soporte de Booteo Gráfico en camino?
Parece que el booteo gráfico está en camino en RHL. Algunas partes
del sistema están modificandose para esto. Si editas el archivo /etc/sysconfig/init y
cambias BOOTUP=color por BOOTUP=graphical
luego en el proceso de booteo via /etc/rc.sysinit, el
binario de booteo gráfico de Red Hat, /usr/bin/rhgb, es
ejecutado . Red Hat debería moverlo a /bin o
a /sbin ya que
el binario sería requerido antes de que /usr sea montado. Antes
de que te emociones demasiado, el binario rhgb no fue incluído
en RHL9.
El GNOME Display Manager (GDM) 2.4.1.3-5
El GDM version 2.4 en RHL8.0 y RHL9 es una significativa mejora del
GDM incluído en RHL7.x. El programa gdmsetup provee una
atractiva interfaz gráfica para configurarlo. Un cambio en RHL9, es que
antes en RHL8.0, GDM era configurado para no reiniciarse incluso si el
servidor X era abortado con CTL-ALT-BKSP. Esto provocaba problemas con
PAM y el servidor X. Esta cuestión se \'arreglaba\' cambiando a modo 3 y
luego de vuelta a modo 5. Probé lo malo de esto mientras estaba dando clases de administración de
sistemas Linux. Ahora, gracias a la opción AlwaysRestartServer=true en /etc/X11/gdm/gdm.conf,
no sucede más.
Luego del primer booteo en RHL8.0, debido a la aplicación de \'primer
booteo\', el servidor X podía terminar en VT 8. Ahora el GDM fuerza el
cambio a la VT 7.
Cuando se usa el GDM en modo \'face browser\' (con íconos para cada
usuario, al estilo Mac OS X o WinXP), las cuentas del sistema no son
mostradas más por defecto.
Scripts de Arranque y Unicode
Todas las utilidades de procesamiento de texto, grep, awk, sort, etc funcionan significativamente
más lentas al usar el seteo local (locale), Unicode UTF. Para
acelerar el arranque, en el script /etc/rc.sysinit y otros
scrips SysV, ya que la configuración usa ASCII de 7bits, éstas
utilidades son llamadas con el parámetro LC_ALL=C utility
forzándolas a usar el \'locale\' C.
Ejecutar demonios SysV con prioridad modificada
Para un script de inicio Sys V dado, puedes ahora controlar
fácilmente el valor de prioridad (nice), para hacerlo crea el archivo /etc/sysconfig/scriptname
(o edita el archivos si ya existiera), y añade la línea: NICELEVEL=\"X\".
Ejecuta man nice para más información.
La introducción de las etiquetas de dispositivo
(Device Labels)
Ha habido una cuestión de larga data en Linux y es el hecho de si
producen fallos o cambios de hardware, los dispositivos de
almacenamiento pueden \'moverse\' a ubicaciones diferentes. Por ejemplo,
aunque los dispositivos IDE tienen su camino físico implícito en su
nombre de dispositivo, por ej. /dev/hdc3, los
dispositivos SCSI no. Considere una situación en la que en un sistema
hay tres discos SCSI (sda, sdb, sdc), y se produce un fallo en sdb, en
el siguiente booteo, el actual sdc se \'deslizará\' hacia abajo y se
volverá sdb. Este tipo de eventos puede ocurrir en muchos escenarios
diferentes, incluso con dispositivos IDE.
Un intento de resolver esta cuestión es el uso de etiquetas de
sistemas de archivo (filesystem labels). Recordarás que hace un par de
años, RHL comenzó a usar etiquetas de sistemas de archivo en el archivo /etc/fstab. El uso de éstas no solucionó el problema por
completo ya que algunas particiones no tienen sistema de archivo (ej. la
de swap), o en el caso de los dispositivos raw usando en ambientes SAN
y en instalaciones Oracle. Últimamente se añadió el problema de que
algunos sistemas de archivo no soportan etiquetas en absoluto.
El sistema devlabel
producido por ingenieros
de Dell y ahora integrado en RHL9 resuelve el problema de fondo de
una manera elegante y conveniente. Es usado por el administrador del
sistema y éste debe definir un nombre mediante el cual será conocida en
adelante cierta partición. Este \'nombre\' es en realidad un enlace
simbólico que devlabel
mantiene actualiza en cada booteo de la máquina (devlabel desde el /etc/rc.sysinit) o por
al administrador del sistema en forma manual.
Además está integrado al sistema hot-plug (conexión en caliente), para
que dispositivo hot-plug como los USB, Firewire o PCMCIA sean
habilitados para usarlos sin tener que rebootear la máquina. Imagínese
tratando de acceder a los archivos guardados en un llavero USB (pequeño
dispositivo de almacenamiento USB de baja capacidad que tiene forma de
llavero para hacer más práctico llevarlo siempre \'encima\'), cuando ya
tienes conectado tu reproductor MP3/OGG. Con devlabel puedes hacer que
el reproductor sea asociado siempre a, por ej., /dev/mp3oggplayer sin
importar cuantos dispositivos o en que orden los conectaste al sistema.
También hay muchos beneficios de devlabel a ambientes SAN, donde una
unidad de disco dada es /dev/sdb
en un host, pero es /dev/sdd
en otro. Usando devlabel
todos los host pueden tener una visión persistente y común de los
archivos de dispositivo.
Es de esperar que por su practicidad, otras distribuciones adopten el
uso de devlabel.
Para obtener más información lea en el sitio de DELL el white
paper, la página man de devlabel.
Cambios en las utilidades de configuración de Red
Hat
En versiones anteriores, RH usaba Linuxconf como el administrador
principal del sistema. Un programa de este tipo que nunca se incluyó en
RH es Webmin. En ambos casos es difícil mantenerse al tanto de estos
desarrollos externos y sincronizarlos con los archivos específicos de
RH. En el pasado hubieron problemas de esta índole al estar Linuxconf y
RH no muy bien integrados, así que decidieron no incluir más Linuxconf
como la utilidad principal de configuración del sistema; ahora en cambio
RH desarrolló sus propios programas. Hay una convención para los
nombres de estos y hace que sea fácil recordarlos y asociarlos a una
tarea en especial sin saberlos de memoria. Usando la característica de
autocompletado de la consola es imposible no encontrar la herramienta
que se busca, por ejemplo:
[root@mentor root]# redhat-config-<presionar
TAB dos veces>
redhat-config-bind
redhat-config-packages
redhat-config-bind-gui
redhat-config-printer
redhat-config-date
redhat-config-printer-gui
redhat-config-httpd
redhat-config-printer-tui
redhat-config-keyboard
redhat-config-proc
redhat-config-kickstart
redhat-config-rootpassword
redhat-config-language
redhat-config-samba
redhat-config-mouse
redhat-config-securitylevel
redhat-config-network
redhat-config-services
redhat-config-network-cmd
redhat-config-soundcard
redhat-config-network-druid
redhat-config-time
redhat-config-network-gui
redhat-config-users
redhat-config-network-tui
redhat-config-xfree86
redhat-config-nfs
[root@mentor root]#
Una nueva herramienta sin equivalente en versiones anteriores es redhat-config-samba que
provee una interfaz gráfica para la configuración de SAMBA.
CUPS es ahora el manejador de impresiones por
defecto
He sido un fan de CUPS desde que salió y lo suelo instalar por mi
cuenta en mis máquinas RHL. Red Hat ha incluído CUPS como alternativa a
LPRng desde RHL7.3, en RHL9 está configurado por defecto. El subsistema
de impresión CUPS tiene muchas ventajas sobre LPD y LPRng, lo primero
que viene a mi memoria es el soporte para el Internet Printing Protocol (IPP) y archivos PostScript Printer
Definition (PPD).
El protocolo IPP es el nuevo estándar de comunicación para impresión en
red. Windows 2000 y XP tienen soporte IPP y Win9x y NT lo tienen via una
actualización que se puede bajar desde el sitio de Microsoft. Desde la
perspectiva de un cliente Windows, esto significa que una máquina
Windows pueda imprimir en una impresora compartida conectada a una
máquina Linux usando CUPS sin otro software adicional (no hace falta
instalar el \'addon\' \"Print Services for UNIX\"). IPP tiene la seguridad
bien definida y certificados x509 para usuarios pueden ser creados y
usados y los trabajos a imprimir se pueden enviar sobre SSL.
Todas las impresoras PostScript, soportan algún nivel de la
especificación (1, 2, 3 etc). El spec define como un trabajo a imprimir
puede hacer uso de características comunes de impresión como el
\'duplexado\'. Pero el spec no define como usar determinadas y útiles
características de ciertas impresoras la precisión de color (Automatica,
SWOP Press, SRGB Display, Fuji Proof, etc). Por ello los fabricantes de
impresoras crean archivos PPD que describen como activar y usar estas
características avanzadas. Piensa en un PPD como si fuera un driver de
impresora. Lo bueno de los PPD es que están escritos en PostScript un
formato ASCII, que es multiplataforma. Si tienes una impresora
PostScript (o una no-PostScript, pero usas el sistema de impresión
foomatic para generar un PPD \'falso\'), cuando crees una entrada para
usarla en CUPS puedes elegir que PPD usar. El resultado es una
impresión por trabajo, donde puedes modificar cualquier
parámetro/característica que quieras usar de la impresora. Para poder
hacer esto instala la impresora usando lpadmin de CUPS (el
configurador de impresora de red hat no
soporta archivos PPD aún). Por ejemplo, aquí en Guru Labs tenemos
una impresora Tektronix Phaser 860 PostScript 3, para añadirla usamos el
comando:
# lpadmin -p phaser860
-E -P /etc/tk860dp1.ppd -v http://phaser860.gurulabs.com:80/ipp/
Para ver qué opciones son específicas para la impresora ejecutar \"lpoptions -l\". Luego al
enviar un trabajo a imprimir con lpr, usa la opción -o. También podrías usar
el sistema de impresión de KDE (incluso dentro de GNOME), kprinter para tener una
interfaz gráfica donde puedes modificar fácilmente todas las opciones
para la impresora. Ve un screenshot de kprinter usando CUPS en
una impresora PPD aquí.
Tip: Aquí en Guru Labs,
ejecutamos el siguiente comando (todo va en una sola línea), como root
en todas nuestras pcs para que Mozilla use kprinter:
# perl -e
\'s/lpr/kprinter --stdin/g\' -pi /usr/lib/mozilla*/defaults/pref/unix.js
Cambios en el Instalador
Como está documentado en las NOTAS DE
LIBERACIÓN la posibilidad de iniciar la instalación desde diskette
ha cambiado. El cambio más importante es que para hacer una
instalación de red necesitaremos dos diskettes; en vez de usar diskettes
para este tipo de instalación considere como opción crear un cdrom de
booteo de la imagen boot.iso. Lea las NOTAS DE
LIBERACIÓN para más detalles.
Una buena característica para los que escriben (como yo mismo), es la
posibilidad de hacer screenshots durante la instalación usando la
combinación de teclas SHIFT+PrntScrn. Las imágenes son guardadas en el
directorio /root/anaconda-screenshots/.
Finalmente, el instalador no ofrece más la posibilidad de usar fdisk para manejar el
disco durante la instalación. Ahora la utilidad recomendada es Disk
Druid. Esto tiene su sentido ya que si usabas fdisk, luego tenías que
usar Disk Druid para definir los puntos de montaje y el formateo. fdisk se puede acceder
desde el shell bash corriendo en paralelo con la instalación (cambia a
él con CTL-ALT-F2).
Cambios notables en los paquetes de software
incluídos
OpenSSH 3.5p1 vs 3.4p1
Cuando se está usando sftp el comando ls soporta el parámetro \"-l\" y el uso de
comodines (por ej., *txt) es soportado por ls, get, y put. Otros detalles: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103470915430194&w=2
Mailman 2.1 vs 2.0.13
El muy capaz administrador de listas de correos , Mailman fue actualizado a la muy
esperada versión 2.1. Esta nueva versión tiene muchas \'cosillas\' muy
buenas. Ve la lista de estas aquí.
Mi favorita es la adición del soporte VERP para el manejo de
reenvios. Por muchos años he ejecutado la tríada de listas de correo qmail+ezmlm+idx, y fue una desilusión ver que
esta característica no estaba cuando me cambié a mailman 2.0. Si usas
Mailman con Postfix asegúrate de
darle una mirada al script de Guru Labs postfix-to-mailman.
OpenSSL 0.9.7a vs 0.9.6b
Esta librería criptográfica es usada por muchos programas. En RHL9
fue actualizada a la versión 0.9.7. Una característica nueva es la
inclusión de Elliptic Curve Crypto, AES, y el soporte para el
criptoalgoritmo MIT Kerberos. Vea la lista completa de cambios aquí.
Subversion 0.17.1
Algo nuevo realmente en RHL9 es inclusión de un sistema de control
de versiones por red llamado, Subversion. Es un
reemplazo avanzado del viejo CVS.
Está planeado que soporte todas las características de CVS además de
otras nuevas y muy útiles.
No lo he usado aún y no estoy seguro de ya se hayan implementado las
características que presume tener. Hablando de reeemplazos para CVS, el
otro contendiente en esta batalla ARCH, no fue incluído
en RHL (todavía).
GNOME 2.2 vs 2.0
La diferencia visual de GNOME en RHL9 vs RHL8 no es mucha. Un buen
cambio de RH es que el menú ha sido reimplementado y el menú \"Extras\"
ya no está y fue reemplazado por una subopción presente en cada rama del
menú llamada \"Más\". Esto también cambió en KDE ya que el nuevo menú es
compartido por ambos. Me gustó particularmente el nuevo applet de
monitoreo de conexiones wireless. Vea la lista completa de cambios aquí.
KDE 3.1 vs 3.0
Muchas nuevas características se introdujeron en KDE 3.1. Una muy
destacable es la posibilidad de compartir el escritorio de forma remota
usando VNC y otra es el uso de
tabuladores en el navegador Konqueror. Vea la lista de cambios aquí.
Evolution 1.2.2 vs 1.0.8
Después de usar Pine
como cliente de correo durante más de una década, finalmente encontré un
cliente de correo gráfico que me agrada. Ximian\'s Evolution lo hace
bien. La nueva versión estable v1.2 está incluída en RHL9 y tiene
grandes mejoras para hace su uso más intuitivo. Algunas de las
características que estoy usando de v1.2 son el soporte LDAP sobre
SSL/STARTTLS, notificación sonora de nuevo correo entrante, y he
ahorrado mucho espacio de disco con el nuevo mecanismo de indexación de
v1.2 Vea la lista completa de cambios aquí.
Si te sientes con ganas de experimentar, podrías probar la nueva
versión basada en GTK2 en desarrollo y que será Evolution
1.4.
Mozilla 1.2.1 vs 1.0.1
El proyecto Mozilla ya tiene cinco años de trabajo y se ha vuelto un
flujo constante de mejoras. En el último año pasaron de la versión 1.0 a
la 1.3 pasando solo por un intermedio,y estable, 1.2.1 el que estaba
listo al momento de la liberación de RHL9 y fue incluído. Hay pocos
cambios en el navegador desde la 1.01 a la 1.2.1, los más visibles son
el uso de GTK2 y una mejor integración para el uso de fuentes
coincidiendo con GNOME en el uso del antialiasing para mostrarlas. Otra
característica muy popular es la posibilidad de añadir a los bookmarks
un grupo de tabs como un solo bookmark e incluso setear un grupo de tabs
como tu \'home page\'. Con esta versión de Mozilla es importante que uses
el más
reciente plugin Flash disponible, ya que versiones anteriores
cuelgan el navegador.
Si quieres actualizarte a Mozilla 1.3 debes saber que se conocen
ciertos problemas de compatibilidad en el plugin java usando la JRE/SDK
de SUN, pero el JRE/SDK
de Blackdown funciona muy bien.
GnomeMeeting 0.96 vs 0.93
GnomeMeeting es una muy buena y pulida aplicación para
videoconferencia y telefonía mediante Voz sobre IP. Red Hat Linux 9
incluye la versión 0.96 que tiene muchas nuevas
características, incluyendo la habilidad de iniciar una llamada a
cualquier teléfono (común), en el mundo, esto requiere la obtención y
pago de una cuenta
MicroTel. Vea las tarifas telefónicas relacionadas aquí.
Samba 2.2.7a vs 2.2.5
Han habido cien cambios, la mayoría arreglos de bugs, desde la
versión 2.2.5 a la 2.2.7. Las notas detalladas de esto aquí.
La diferencia más importante en esta última versión (incluída en RHL9),
es la inclusión del \'winbind\'. Este permite obtener información de
usuarios, grupos y del host desde el servidor NT. Fue implementado como
un demonio, winbindd.
Puedes aprender más sobre esto aquí.
GNUCash 1.8.1 vs 1.6.6
El administrador de finanzas personales (al estilo Quicken), GNUCash
ha tenido una considerable mejora en la versión actualizada incluída en
RHL9. Una de las características principales es la inclusión de los
protocolos Open Financial Exchange (OFX) y el German Home Banking
Computer Information (HBCI). Estos permiten hacer distintas operaciones
bancarias online como por ejemplo transferencias entre cuentas,
solicitar estados de cuenta, etc. en muchos bancos y entidades de
crédito que se manejan por medio de OFX y HBCI. Vea la lista completa de
cambios aquí.
Rdesktop 1.2.0 vs 1.1.0
El cliente rdesktop (y el
frontend gráfico GNOME tsclient ), permiten
la conexión a Windows Terminal Servers, incluído el servidor
interconstruído en XP. En RHL9, fue incluída la última versión estable,
la 1.2 que tiene características como mapeo del teclado, soporte de
criptografía fuerte para la conexión y otros arreglos y mejoras.
Conclusion
Red Hat Linux 9 es un sólido ejemplo de lo último en Linux y en
tecnología de software de código abierto. Lo he estado usando y
testeando a través de las tres betas y en su versión final y estoy muy
satisfecho. Próximamente actualizaremos todas las máquinas de los
laboratorios Guru.
Acerca del Autor
Residente de Salt Lake City, Utah, Dax Kelson es un instructor
senior (y Presidente de la comañía en sus días libres), de Guru Labs,
LLC, una empresa dedicada a la enseñanza de Redes y Seguridad en Linux,
trabajando desde hace cuatro años. Dax instaló su primer Linux en 1993
usando la distribución SLS, más tarde trabajó con Slackware y con todas
las versiones de Red Hat desde aquella del Día de la Madre. El fundó,
administró y vendió Internet Connect un ISP de gran tamaño en Utah desde
1996 hasta 1999. Logró su certificación RHCE en febrero de 1999 sobre
Red Hat Linux 5.2 con una puntuación perfecta. Luego de pasar el exámen
de dos días de duración, para ser un Certified Cisco Systems Instructor
(CCSI), se convirtió en un Instructor de Redes y Seguridad en Solaris
de Sun.
Copyright © 2003
by Guru Labs, L.C., All rights reserved.
Relacionado con Cambios Técnicos no documentados en Red Hat Linux 9
