[Índice de documentos] [Sección 7 - Controles de teclado y pantalla] [Sección 9 - Migrando desde un sistema Linux
La puede recuperar siguiendo los pasos a continuación
Si tiene totalmente configurado X y está usando un fichero XF86Config que sabe con seguridad que es correcto, entonces es posible que el problema se encuentre en machdep.allowaperture. Asegúrese también de que
option APERTURE
esté en la configuración del núcleo de su sistema (ya se encuentra en el núcleo GENERIC).
Para solucionarlo, edite el fichero /etc/sysctl.conf para permitir que X pueda acceder al controlador de apertura; escriba machdep.allowaperture=2. Si durante la instalación se hubiera contestado que sí a la pregunta sobre si quería tener XWindows funcionando, esta configuración aparecería por definición. OpenBSD requiere que todos los servidores de X tengan activado el acceso al controlador de apertura, debido a que controla el acceso a los puertos E/S en las placas de vídeo.
Si tiene otros problemas con X en i386, consulte la documentación de XFree86 en http://www.xfree86.org/support.html.
CVS es la herramienta que utiliza el Proyecto OpenBSD para controlar los cambios al código fuente. CVS son las siglas de "Concurrent Versions System" («Sistema de Versiones Concurrentes»). Puede obtener más información sobre CVS en http://www.cvshome.org/. CVS puede ser utilizado por un usuario final para mantenerse sincronizado con los cambios en los fuentes, y con los cambios en el árbol de portes. Con CVS es muy fácil bajarse los fuentes a través de uno de las muchas réplicas de CVS del Proyecto.
Puede obtener el código fuente desde uno de los servidores de AnonCVS de OpenBSD. Puede encontrar una lista de estos servidores en http://www.openbsd.org/es/anoncvs.html. Después de escoger un servidor, deberá escoger el módulo que vaya a bajarse. Existen tres módulos principales disponibles desde el árbol de CVS, que son:
Ahora que ya ha decidido qué módulo desea obtener, queda un paso más que tendrá que llevar a cabo para poder obtenerlo. Debe decidir qué método usar. Por definición, CVS baja los ficheros usando ssh(1), pero algunos servidores de AnonCVS puede permitir el uso de rsh(1). Para los que se encuentren detrás de un cortafuegos, existe la opción de pserver y de algunos servidores que permiten el acceso ssh por el puerto 2022. Asegúrese de leer http://www.openbsd.org/es/anoncvs.html para saber qué protocolos están soportados en los diferentes servidores. A continuación mostraremos un ejemplo sobre cómo llevar a cabo una simple descarga del código fuente. En este ejemplo usaremos un servidor de CVS anónimo ubicado en los EE.UU., pero recuerde que si Vd se encuentra fuera de los EE.UU. debe usar un servidor que esté ubicado más cerca de Vd. Hay muchos servidores de CVS anónimo por todo el mundo, así que escoja el que tenga más cerca. También usaré ssh para bajar los ficheros.
$ export CVSROOT=anoncvs@anoncvs.usa.openbsd.org:/cvs
$ cvs get src
Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side.
cvs checkout: in directory src:
cvs checkout: cannot open CVS/Entries for reading: No such file or directory
cvs server: Updating src
U src/Makefile
[snip]
Nótese que también se ha activado la variable de entorno CVSROOT. Esta variable indica a cvs(1) el servidor de CVS Anónimo que debe utilizar. También se puede especificar esta variable usando la opción -d, por ejemplo:
$ cvs -d anoncvs@anoncvs.usa.openbsd.org:/cvs get src
Estas órdenes deberían ser ejecutadas desde el directorio /usr, ya que así se crearán los directorios /usr/src, /usr/ports, y /usr/www, dependiendo, por supuesto, del módulo que indique para bajar. Puede bajarse estos módulos en cualquier parte, pero si lo que quiere es trabajar con ellos (o sea, 'make build'), se supone que deben estar en los directorios arriba mencionados.
Una vez que haya obtenido su árbol inicial, mantenerlo actualizado será una tarea fácil. Puede actualizar en cualquier momento que desee; algunos servidores de CVS Anónimo se actualizan con más frecuencia que otros, por lo que deberá comprobar http://www.openbsd.org/es/anoncvs.html. En el siguiente ejemplo actualizaremos el módulo www desde anoncvs.usa.openbsd.org. Fíjese en la opción -q que usaremos, sirve para que la información en pantalla que nos llegue del servidor no sea excesiva.
$ echo $CVSROOT
anoncvs@anoncvs.usa.openbsd.org:/cvs
$ cvs -q up -Pd www
Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side.
U www/want.html
M www/faq/faq8.html
$
Para algunos, el ancho de banda y el tiempo de conexión representan serios problemas cuando actualizan desde repositorios como éstos. CVS tiene una opción -z[1-9] que usa gzip para comprimir los datos. Para usar esta opción añada -z[nivel-de-compresión]; por ejemplo, -z3 para un nivel 3 de compresión.
El árbol de portes es un conjunto de ficheros Makefile listos para ser bajados, parcheados, configurados e instalados en programas de modo usuario para que pueda ejecutarlos en el entorno de OpenBSD sin tener que hacerlo todo a mano. Puede obtener el árbol de portes desde el directorio /pub/OpenBSD/3.4/ports.tar.gz en cualquiera de los servidores de FTP de OpenBSD. Los portes más recientes se encuentran disponibles desde el módulo "ports" del árbol de cvs, o por ftp en /pub/OpenBSD/snapshots/ports.tar.gz. Sin embargo, para la mayoría de usuarios, instalar los paquetes en lugar de los portes será una opción mejor. Los paquetes se generan desde los portes, y vienen precompilados y listos para usar. Para más información sobre los paquetes, lea la sección sobre paquetes.
OpenBSD tiene en todo momento tres versiones «activas»:
¡NO mezcle versiones del sistema y de los portes de OpenBSD distintas!
Si su sistema pertenece a la versión final (-release), use la versión final del árbol de portes. No intente usar una versión en desarrollo (-current) del árbol de portes en un sistema de la versión final o estable (-stable). Esto no sólo no funcionará, sino que causará molestias en las listas cuando pida ayuda porque «nada funciona». Nótese que también hay una rama -stable del árbol de portes, a la que se le aplican las reparaciones críticas de los portes de la rama -release.
En efecto, esto quiere decir que un nuevo porte no funcionará con casi total seguridad en un sistema «viejo» (aun en el caso en que el sistema sea de una versión de desarrollo de hace sólo unas pocas semanas).
Si no tiene el árbol de portes instalado, puede obtenerlo por
medio de cualquiera de los servidores de
FTP de OpenBSD o, por supuesto, mediante el
CD-ROM. El archivo con los portes es
ports.tar.gz, y debe desempaquetarlo en el directorio
/usr, creando /usr/ports, del siguiente modo:
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/3.4/ports.tar.gz
$ sudo cp ports.tar.gz /usr
$ cd /usr; sudo tar xzf ports.tar.gz
También se crea a diario una archivo preliminar del árbol de portes que se puede obtener desde cualquiera de los servidores de FTP de OpenBSD como /pub/OpenBSD/snapshots/ports.tar.gz. Si va a instalar una versión preliminar (snapshot) del sistema de OpenBSD, deberá usar un archivo preliminar de los portes que coincida con aquélla. Insistimos en que debe mantener su árbol de portes y el sistema de OpenBSD sincronizados.
Use el árbol de portes para buscar palabras claves. Para ello use make search key="palabra_clave". A continuación puede ver un ejemplo de una búsqueda de 'samba':
$ make search key="samba"
[...]
Port: amanda-client-2.4.2.2
Path: misc/amanda,-client
Info: network-capable tape backup (client only)
Maint: Tom Schutter <t.schutter@att.net>
Index: misc
L-deps:
B-deps: :devel/gmake gnuplot-*:math/gnuplot gtar-*:archivers/gtar samba-*:net/samba/stable
R-deps:
Archs: any
Port: samba-2.2.8a
Path: net/samba/stable
Info: SMB and CIFS client and server for UNIX
Maint: The OpenBSD ports mailing-list <ports@openbsd.org>
Index: net
L-deps: popt::devel/popt
B-deps: :devel/autoconf/2.13 :devel/metaauto
R-deps:
Archs: any
[...]
Los portes se configuran para que sean EXTREMEDAMENTE fáciles de compilar e instalar. A continuación sigue un ejemplo en donde se muestra como instalar el programa xfig para X11. Podrá observar que las dependencias se detectan y resuelven de forma automática.
Para empezar necesita cambiar al directorio del programa que desea. Si está buscando un programa, puede actualizar su base de datos local, o bien usar la función de búsqueda que se ha mencionado anteriormente. Una vez que se encuentre en el directorio el programa que desee instalar, ejecute make install. Por ejemplo:
$ sudo make install
===> Checking files for xfig-3.2.4
>> xfig.3.2.4.full.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch /usr/ports/distfiles/xfig.3.2.4.full.tar.gz from http://w
ww.xfig.org/xfigdist/.
100% |**************************************************| 5042 KB 00:31
>> Checksum OK for xfig.3.2.4.full.tar.gz. (sha1)
===> xfig-3.2.4 depends on: jpeg.62 - jpeg.62 missing...
===> Verifying install for jpeg.62 in graphics/jpeg
===> Checking files for jpeg-6b
>> jpegsrc.v6b.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch /usr/ports/distfiles/jpegsrc.v6b.tar.gz from ftp://ftp.uu
.net/graphics/jpeg/.
'EPSV': command not understood.
100% |**************************************************| 598 KB 00:06
>> Checksum OK for jpegsrc.v6b.tar.gz. (sha1)
===> Extracting for jpeg-6b
===> Patching for jpeg-6b
===> Configuring for jpeg-6b
checking for gcc... cc
checking whether the C compiler (cc -O2 ) works... yes
checking whether the C compiler (cc -O2 ) is a cross-compiler... no
checking whether we are using GNU C... yes
[...]
Muchas de las aplicaciones en el árbol de portes tienen soporte para diferentes opciones de instalación, llamadas flavors («sabores»). Si un porte tiene múltiples opciones, puede usar estas opciones configurando una variable de entorno antes de compilar el porte. Si se necesita varias de las opciones, se puede configurar la variable FLAVOR como una lista delimitada por espacios de las opciones que se deseen y de que se dispongan. En este momento, muchos portes disponen de opciones que incluyen soporte para bases de datos, para sistemas sin X, o adiciones de red como SSL e IPv6.
$ pwd
/usr/ports/net/mtr
$ make show=FLAVORS
no_x11
$ env FLAVOR="no_x11" make
===> mtr-0.49-no_x11 depends on: gmake-3.80 - not found
===> Verifying install for gmake-3.80 in devel/gmake
===> Checking files for gmake-3.80
>> make-3.80.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch /usr/ports/distfiles/make-3.80.tar.gz from ftp://ftp.gnu.
org/gnu/make/.
Unknown command.
100% |**************************************************| 1183 KB 00:07
>> Checksum OK for make-3.80.tar.gz. (sha1)
[...]
$ sudo env FLAVOR="no_x11" make install
===> Faking installation for mtr-0.49-no_x11
[...]
===> Building package for mtr-0.49-no_x11
Creating package /usr/ports/packages/i386/All/mtr-0.49-no_x11.tgz
Using SrcDir value of /usr/ports/net/mtr/w-mtr-0.49-no_x11/fake-i386-no_x11/usr/
local
Creating gzip'd tar ball in '/usr/ports/packages/i386/All/mtr-0.49-no_x11.tgz'
===> Installing mtr-0.49-no_x11 from /usr/ports/packages/i386/All/mtr-0.49-no_a
x11.tgz
Puede ver una lista, tanto para portes como para paquetes, usando la orden pkg_info.
$ /usr/sbin/pkg_info
zsh-4.1.1 The Z shell.
screen-3.9.15 A multi-screen window manager.
emacs-21.3 GNU editing macros.
tcsh-6.12.00 An extended C-shell with many useful features.
bash-2.05b The GNU Borne Again Shell.
zip-2.3 Create/update ZIP files compatible with pkzip.
ircII-20030314 An enhanced version of ircII, the Internet Relay Chat client
ispell-3.2.06 An interactive spelling checker.
tin-1.6.1 TIN newsreader (termcap based)
procmail-3.22 A local mail delivery agent.
strobe-1.06 Fast scatter/gather TCP port scanner
lsof-4.68 Lists information about open files.
ntp-4.1.74 Network Time Protocol Implementation.
ncftp-3.1.5p0 ftp replacement with advanced user interface
nmh-1.0.4p1 The New MH mail handling program
bzip2-1.0.2 A block-sorting file compressor
Puede encontrar más información sobre los portes en la página del manual de ports(7) o en la página sobre portes.
Nuestro árbol de fuentes se encuentra en contínua expansión; si quiere ayudar, por favor lea http://www.openbsd.org/es/porting.html.
Los paquetes son binarios precompilados de algunos de los programas más usados. Están preparados para usarlos directamente en un sistema OpenBSD. Al igual que los portes, los paquetes son muy fáciles de mantener y actualizar. Asegúrese de comprobar qué paquetes adicionales existen para cada versión del sistema, ya que continuamente se están añadiendo paquetes nuevos.
Aquí puede ver una lista de las herramientas que se utilizan para
gestionar paquetes.
Si es Vd. un usuario avispado y compró los CDs de OpenBSD, entonces podrá encontrar los paquetes en uno de los tres CDs, dependiendo de su arquitectura. Si no dispone de los CDs de OpenBSD, puede obtener los paquetes bajándoselos de cualquiera de las réplicas del servidor de ftp. Hay una lista de las réplicas del servidor de ftp en http://www.openbsd.org/es/ftp.html. Los paquetes están ubicados en /pub/OpenBSD/3.4/packages; desde ahí los paquetes se subdividen dependiendo de la arquitectura.
Para instalar paquetes se utiliza la herramienta pkg_add(1). pkg_add(1) es muy fácil de usar, y en los dos ejemplos que aparecen a continuación puede ver cómo instalar un paquete con pkg_add(1). El primer ejemplo muestra cómo instalar con pkg_add(1) un paquete que esté ubicado en un disco local, mientras que el segundo ejemplo muestra la instalación de un paquete por medio de ftp. En ambos ejemplos se instalará screen-3.9.15.
Instalación desde un disco local
$ sudo pkg_add -v screen-3.9.15.tgz
Requested space: 749864 bytes, free space: 2239117312 bytes in /var/tmp/instmp.cpsHA27596
Running install with PRE-INSTALL for `screen-3.9.15'
extract: Package name is screen-3.9.15
extract: CWD to /usr/local
extract: /usr/local/bin/screen-3.9.15
extract: execute 'ln -sf screen-3.9.15 /usr/local/bin/screen'
extract: /usr/local/man/man1/screen.1
extract: /usr/local/info/screen.info
extract: execute '[ -f /usr/local/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > /usr/local/info/dir'
extract: execute 'install-info /usr/local/info/screen.info /usr/local/info/dir'
extract: /usr/local/lib/screen/screencap
extract: /usr/local/lib/screen/screenrc
extract: CWD to .
Running mtree for `screen-3.9.15'
mtree -q -U -f +MTREE_DIRS -d -e -p /usr/local
Running install with POST-INSTALL for `screen-3.9.15'
+---------------
| The file /etc/screenrc has been created on your system.
| You may want to verify/edit its contents
|
| The file /usr/local/lib/screen/screencap contains a
| termcap like description of the screen virtual terminal.
| You may use it to update your terminal database.
| See termcap(5).
+---------------
Attempting to record package into `/var/db/pkg/screen
Package `screen-3.9.15' registered in `/var/db/pkg/screen-3.9.15'
En este ejemplo se ha usado el indicador -v para obtener una salida con más información; esta opción no es necesaria, pero ayuda a depurar y se ha usado aquí para ofrecer una visión más detallada del proceso llevado a cabo por pkg_add(1). Habrá notado que aparece un mensaje en el que se menciona el fichero /etc/screenrc. Este tipo de mensaje aparecerán tanto si usa la opción -v como si no.
Instalación desde ftp
$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/3.4/packages/i386/screen-3.9.15.tgz
>>> ftp -o - ftp://ftp.openbsd.org/pub/OpenBSD/3.4/packages/i386/screen-3.9.15.tgz
+---------------
| The file /etc/screenrc has been created on your system.
| You may want to verify/edit its contents
|
| The file /usr/local/lib/screen/screencap contains a
| termcap like description of the screen virtual terminal.
| You may use it to update your terminal database.
| See termcap(5).
+---------------
En este ejemplo puede observar que se ha instalado el paquete indicando la arquitectura i386. Si la arquitectura es otra distinta, entonces hay que sustituir i386 (en el ejemplo anterior) con la arquitectura correspondiente. Nótese que no todas las arquitecturas disponen de los mismos paquetes. Algunos portes no funcionan en ciertas arquitecturas. En el ejemplo no se ha usado la opción -v, así que sólo se ha mostrado la información NECESARIA.
Para ver una lista de todos los paquetes que se encuentren instalados en su sistema, puede usar la herramienta pkg_info(1). Por regla general, necesitará usar esta herramienta para poder ver el nombre exacto de un paquete antes de proceder a su eliminación. Para ver qué paquetes se encuentran instalados en su sistema, ejecute la siguiente orden:
$ pkg_info
mpg123-0.59rp1 mpeg audio 1/2 layer 1, 2 and 3 player
nmap-3.00 port scanning large networks
ircII-20030314 enhanced version of ircII (internet relay chat)
screen-3.9.15 multi-screen window manager
unzip-5.50r2 extract, list & test files in a ZIP archive
ntp-4.1.74 Network Time Protocol implementation
icb-5.0.9p1 Internet CB - mostly-defunct chat client
Para eliminar un paquete, tome el nombre del paquete tal y como se muestra con la orden pkg_info(1), y use la herramienta pkg_delete(1) para eliminarlo. En el siguiente ejemplo se muestra cómo eliminar el paquete screen. En algunos casos existen instrucciones sobre algunos objetos que deben ser eliminados y que pkg_delete(1) no eliminará, y que por tanto deberá eliminarlos Vd. mismo. Como se hizo anteriormente con pkg_add(1), puede usar la opción -v para obtener una información más amplia del proceso.
$ sudo pkg_delete screen-3.9.15
+---------------
| To completely deinstall the screen-3.9.15 package you need to perform
| this step as root:
|
| rm -f /etc/screenrc
|
| Do not do this if you plan on re-installing screen-3.9.15
| at some future time.
+---------------
Como regla general, es MUY recomendable usar los paquetes antes que compilar una aplicación desde los portes. El equipo de portadores de OpenBSD considera que los paquetes son el objetivo final de su trabajo, y no los portes en sí.
La compilación de una aplicación a partir del código fuente no es una tarea trivial. La aplicación no sólo debe compilarse , sino que también deben compilarse las herramientas necesarias para su compilación. Desafortunadamente, tanto OpenBSD como las herramientas y las aplicaciones son código en evolución, y con frecuencia es todo un reto conseguir que todas las piezas funcionen juntas. Una vez que todo esté funcionando, una revisión en cualquiera de las piezas al día siguiente puede echarlo todo a perder. Cada seis meses, según sale una nueva versión final de OpenBSD, se lleva a cabo un esfuerzo por realizar pruebas de control de la compilación de cada uno de los portes en cada una de las plataformas, pero es muy posible que algo se estropee durante el ciclo de desarrollo.
Además de conseguir que todas las piezas funcionen al unísono, también está el asunto del tiempo y los recursos que se requieren para compilar algunas aplicaciones a partir del código fuente. Un ejemplo muy común es el de CVSup, una herramienta que suele usarse para el seguimiento del árbol de fuentes de OpenBSD. La instalación de CVSup en un sistema moderadamente rápido con una conexión a Internet decente puede tardar sólo unos diez segundos, el tiempo necesario para descargar y desempaquetar un archivo de paquete de 511kB. En contraste, compilar CVSup a partir del código fuente en esa misma máquina es una tarea de enormes dimensiones, y para la que se necesitan muchas herramientas y un mecanismo de arranque para un compilador, se tardaría casi media hora. Otras aplicaciones, como Mozilla o KDE, pueden tardar horas y consumir grandes cantidades de espacio en disco y de memoria de RAM/swap para la compilación. ¿Para qué tanto tiempo y esfuerzo cuando los programas ya están compilados y esperando a ser usados en el CD-ROM o en la réplica del servidor de FTP?
Por supuesto que hay casos en los que existen unas cuantas buenas razones para usar los portes en lugar de los paquetes:
Sin embargo, para la mayoría de usuarios y de aplicaciones, el uso de los paquetes es mucho más fácil, además de ser el modo recomendado de añadir aplicaciones a OpenBSD.
Sí, para ello hay que configurar el núcleo del sistema de forma que siempre asuma que hay una disquetera instalada, aunque no se detecte durante el sondeo de hardware, activando el indicador de bit 0x20 en fdc(4). Esto se puede hacer usando User Kernel Config, o config(8) para alterar el núcleo del sistema:
# config -e -f /bsd
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MST 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Enter 'help' for information
ukc> change fd*
204 fd* at fdc0 drive -1 flags 0x0
change [n] y
drive [-1] ? ENTER
flags [0] ? 0x20
204 fd* changed
204 fd* at fdc0 drive -1 flags 0x20
ukc> q
Saving modified kernel.
#
También se puede cambiar añadiendo "flags 0x20"
al final de la entrada de fd* en el fichero
de configuración del núcleo, y después
recompilar el núcleo. La línea debe quedar así:
fd* at fdc? drive ? flags 0x20
Al iniciar su sistema OpenBSD habrá visto el punto de arranque del sistema.
boot>
La mayoría de los usuarios no tendrán que hacer nada en este punto, ya que iniciará el sistema de forma automática a menos que se le pase alguna orden. Pero algunas veces pueden surgir problemas, o se puede necesitar de alguna función especial. Para entender el punto de arranque debe leer la página del manual de boot(8). En esta sección trataremos únicamente las órdenes más comunes para el gestor de arranque.
En principio, si no se introduce ninguna orden, el gestor de arranque tratará de iniciar la imagen del núcleo /bsd de forma automática. Si esto fallara, intentaría iniciar /obsd y, si esto falla, lo intentará con /bsd.old. Se puede especificar un núcleo de arranque a mano, mediante:
boot> boot hd0a:/bsd
ó
boot> b /bsd
Esto arrancará el núcleo bsd desde la partición 'a' de la primera BIOS reconocida del disco duro.
He aquí una breve lista de opciones que puede usar con el núcleo de OpenBSD.
Estas opciones se introducen de la siguiente forma: boot [ imagen [-acds]]
Para más información, lea la página del manual de boot_i386(8).
S/Key es un esquema de «contraseña de una sola vez». Con S/Key se pueden usar contraseñas que se usarán sólo una vez en canales sin ningún tipo de seguridad implementada. Esto puede ser útil para aquellos que no puedan usar ssh o cualquier otro canal cifrado. La implementación de S/Key en OpenBSD puede hacer uso de varios algoritmos como "hash" de una dirección. Se encuentran disponibles los siguientes algoritmos:
Para empezar debe existir el fichero /etc/skey. Si no existiera este fichero, pídale al administrador que lo cree. Para crear este fichero basta con ejecutar:
# mkdir /etc/skey
Una vez que exista ese directorio, se podrá iniciar S/Key. Para iniciar S/Key hay que usar skeyinit(1). Con skeyinit(1), lo primero que le preguntará será por su contraseña en el sistema. Ésta es la misma que usa para ingresar en el sistema. La ejecución de skeyinit(1) en un canal no seguro no es recomendable, así que debería ejecutarlo por un canal seguro como ssh o desde la consola. Una vez que se haya autorizado a sí mismo mediante la contraseña del sistema, le pedirá que introduzca otra contraseña. Ésta es la contraseña secreta de S/Key, y NO su contraseña del sistema. Su contraseña secreta debe contener un mínimo de 10 caracteres. Le aconsejamos que use como contraseña una frase que pueda recordar y que se componga de varias palabras. En el siguiente ejemplo se muestra cómo añadir un usuario.
oshibana:ericj> skeyinit ericj
[Adding ericj]
Reminder - Only use this method if you are directly connected
or have an encrypted channel. If you are using telnet
or rlogin, exit with no password and use skeyinit -s.
Enter secret password:
Again secret password:
ID ericj skey is otp-md5 99 oshi45820
Next login password: HAUL BUS JAKE DING HOT HOG
La línea ID ericj skey is otp-md5 99 oshi45820 es de especial importancia. Esta línea muestra mucha información al usuario. Analicemos la línea por partes y según importancia:
Pero lo más importante es la contraseña. En el ejemplo, la contraseña consiste de 6 pequeñas palabras que, combinadas e incluyendo espacios y cualquier otro carácter, forman la contraseña.
Ahora que su skey ya ha sido iniciada, y que ya tiene su contraseña, ya está preparado para ingresar. Aquí puede ver una sesión de muestra en la que se usa S/Key para ingresar. A partir de la versión 3.0 de OpenBSD, el ingreso mediante S/Key es diferente. En OpenBSD 3.0 y versiones posteriores debe anteponer :skey a su nombre de ingreso. En las versiones anteriores a OpenBSD 3.0 use s/key para la contraseña y le pedirá su contraseña de S/Key (excepto ftpd(8), que siempre presenta un desafío de S/Key para usuarios con S/Key activado en sistemas anteriores a OpenBSD 3.0). En los ejemplos siguientes se asume que la versión de OpenBSD es la 3.0 o posterior.
oshibana:ericj> ftp localhost
Connected to localhost.
220 oshibana.shin.ms FTP server (Version 6.5/OpenBSD) ready.
Name (localhost:ericj): ericj:skey
331- otp-md5 96 oshi45820
331 S/Key Password:
230- OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MDT 2003
230-
230- Welcome to OpenBSD: The proactively secure Unix-like operating system.
230-
230- Please use the sendbug(1) utility to report bugs in the system.
230- Before reporting a bug, please try to reproduce it with the latest
230- version of the code. With bug reports, please try to ensure that
230- enough information to reproduce the problem is enclosed, and if a
230- known fix for it exists, include that as well.
230-
230 User ericj logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quit
221 Goodbye.
Nótese que he precedido mi nombre de usuario con «:skey». De este modo indico a ftpd que quiero usar S/Key como método de autenticación. Es probable que haya notado que mi número de secuencia ha cambiado a otp-md5 96 oshi45820. Esto se debe a que ya he usado varias veces S/Key para el ingreso. Pero, ¿cómo se obtiene la contraseña después de haber ingresado una vez? Pues bien, para ello debe saber qué número de secuencia está usando y su clave. Probablemente esté pensando en cómo puede recordar qué número de secuencia está usando en ese momento... bueno, esto es fácil, use skeyinfo(1), le dirá el número de secuencia actual. En el ejemplo, hay que generar otra contraseña para un posible ingreso en el futuro (recuerde que en el ejemplo se asume que se encuentra en un canal seguro):
oshibana:ericj> skeyinfo
95 oshi45820
Una forma aún mejor es usar skeyinfo -v, que produce una orden ejecutable por el intérprete de órdenes (shell). Por ejemplo:
oshibana:ericj> skeyinfo -v
otp-md5 95 oshi45820
otp-md5 no es sólo una descripción del resumen criptográfico (hash) usado, sino también un nombre alternativo para la orden skey(1). Por consiguiente, la forma más simple de generar la contraseña de S/Key siguiente es:
oshibana:ericj> `skeyinfo -v`
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
NOOK CHUB HOYT SAC DOLE FUME
Nótense el tipo de comillas usado en el ejemplo anterior.
Como es probable que muchos usuarios no siempre podrán disponer de una conexión segura para generar la contraseña, y generarla en una conexión insegura no es factible, ¿se podrían generar múltiples contraseñas de una sola vez? Sí, ejecute skey(1) con el número de contraseñas que desee generar. Puede imprimir estas contraseñas y llevárselas consigo.
oshibana:ericj> otp-md5 -n 5 95 oshi45820
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
91: SHIM SET LEST HANS SMUG BOOT
92: SUE ARTY YAW SEED KURD BAND
93: JOEY SOOT PHI KYLE CURT REEK
94: WIRE BOGY MESS JUDE RUNT ADD
95: NOOK CHUB HOYT SAC DOLE FUME
Nota: La última contraseña es la primera que deberá usar, ya que es una cuenta atrás desde 100.
Usar S/Key con telnet(1), ssh(1), o rlogin(1) es muy parecido a hacerlo con ftp; sólo tiene que añadir «:skey» al final de su nombre de usuario.
$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OpenBSD/i386 (oshibana) (ttyp2)
login: ericj:skey
otp-md5 98 oshi45821
S/Key Password: SCAN OLGA BING PUB REEL COCA
Last login: Thu Oct 7 12:21:48 on ttyp1 from 156.63.248.77
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MDT 2003
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code. With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
You have mail.
$
Todavía no. Estamos trabajando sobre ello, y existe un proyecto SMP para OpenBSD, aunque no aún no hay nada que se pueda utilizar ni hay una fecha límite para el soporte de SMP.
En la mayoría de las plataformas, OpenBSD funciona en sistemas SMP, aunque sólo utiliza un procesador. La única excepción es la plataforma SPARC. OpenBSD/sparc necesitará algunas veces que se extraigan del sistema los módulos MBus adicionales para que arranque el sistema. Los sistemas con multiprocesador SPARC64 funcionarán siempre y cuando exista soporte para la máquina que se utilice.
¿Cómo se puede ayudar?
Debe usar /dev/cuaXX para conexiones iniciadas desde el sistema OpenBSD; los dispositivos /dev/ttyXX son sólo para uso de terminales o conexiones entrantes. Aunque era posible usar los dispositivos tty, el núcleo de OpenBSD ya no es compatible con este uso.
De la página del manual de cua(4):
Para los puertos de los terminales, existe soporte para conexiones salientes a través de nodos de dispositivos que concuerdan llamados unidades de llamada. Por ejemplo, el terminal /dev/tty03 tendría una unidad de llamada que concordaría, de nombre /dev/cua03. Estos dos dispositivos se diferencian normalmente creando el nodo del dispositivo de la unidad de llamada con un número menor, 128 veces mayor que el del nodo del dispositivo de la conexión entrante. Mientras el dispositivo de llamada entrante (tty) suele necesitar una señal de hardware para indicar al sistema que está activo, el dispositivo de llamada saliente (cua) no, y por lo tanto se puede comunicar sin impedimentos con un dispositivo como pueda ser un modem. Esto quiere decir que un proceso como getty(8) esperará en un dispositivo de llamada entrante hasta que se establezca una conexión. Mientras tanto, se podrá establecer una conexión saliente en el dispositivo de llamada saliente (para el mismo puerto del terminal) sin interferir con ninguna otra parte del sistema. El proceso getty(8) se encargará de ello correctamente, sin haber notado la acción de la llamada saliente.
Lynx es un navegador en modo de texto, forma parte del sistema base y tiene soporte para SSL. Otros navegadores en el árbol de portes son:
Navegadores gráficos (modo X)
Navegadores de Consola (modo texto)
Todos estos navegadores se pueden encontrar en la colección de portes de OpenBSD. Después de la instalación del árbol de portes, se encontrarán en el directorio /usr/ports/www/. La mayoría de ellos también se encuentran disponibles como paquetes precompilados en los servidores de FTP y en el CD-ROM. Dado que la mayoría de los navegadores gráficos son de gran tamaño y tardan mucho en bajarse y compilar, es muy aconsejable usar los paquetes siempre que existan en lugar de compilarlos de los portes.
Debido a un error en una de las bibliotecas usadas por w3m, este navegador no funciona en ninguna de las plataformas de la versión final de OpenBSD 3.4.
mg es un micro editor de texto del estilo de Emacs incluido en OpenBSD. Micro porque es pequeño (¡Emacs es demasiado grande!). Puede encontrar información básica en la página del manual de mg(1) y en el tutorial que también se incluye con el código fuente. Cualquier duda más interesante (como «¡No tengo una tecla Meta!») la puede resolver leyendo las Preguntas Frecuentes de Emacs.
Nótese que debido a que mg es una pequeña implementación de Emacs, y que es más parecido al editor de texto Emacs 17, no tiene implementadas muchas de las otras funciones de Emacs (incluidas las funciones de correo, noticias, y otras como nodos para Lisp, C++, Lex, Awk, Java, etc... ).
Existen dos posibles motivos para que parezca que ksh(1) ignora el fichero .profile de un usuario.
# chown user ~user/.profile
En xterm(1), argv[0] para ksh(1) no va precedido por un guión ('-'). Anteponer un guión a argv[0] hará que csh(1) y ksh(1) sepan que deben interpretar sus ficheros de ingreso (en csh(1) este fichero es .login, con un fichero .cshrc separado que se interpreta siempre que inicia csh(1); en ksh(1) sólo hay un guión de inicio, .profile. Este fichero se ignora a menos que la shell sea una shell de ingreso ("login shell").
Para solucionarlo, hay que añadir la línea "XTerm*loginShell: true" al fichero .Xdefaults de su directorio. Nótese que este fichero no existe y deberá crearlo Vd mismo.
$ echo "XTerm*loginShell: true" >> ~/.Xdefaults
Es posible que no haya tenido que hacer esto en otros sistemas, y es debido a que algunas instalaciones del X Window System vienen con esta configuración predeterminada. OpenBSD ha escogido seguir el modo de XFree86.
El fichero /etc/motd se edita cada vez que se arranca el sistema, sustituyendo hasta la primera línea en blanco excluida con la información sobre la versión del núcleo del sistema. Cuando se edite este fichero hay que asegurarse de empezar después de esta línea en blanco, para evitar que /etc/rc elimine esas líneas cuando edite /etc/motd durante el arranque.
Aunque ninguno de los desarrolladores piense que sea de particular importancia, esta pregunta aparece en las listas de correo con la frecuencia suficiente como para que sea contestada aquí. www.openbsd.org y el sitio de ftp principal de OpenBSD están hospedados en un SunSITE en la Universidad de Alberta, en Canadá. Estos sitios están hospedados en un gran sistema Sun, que dispone de acceso a grandes cantidades de espacio de almacenamiento y de ancho de banda de Internet. La presencia del SunSITE permite al grupo de OpenBSD acceso a este ancho de banda. Ésta es la razón por la que el sitio principal está aquí hospedado. Muchos de las réplicas están hospedadas en sistemas OpenBSD, pero como no tienen garantizado el acceso a esta gran cantidad de ancho de banda, el grupo escogió hospedar el sitio principal en el SunSITE de la Universidad de Alberta.
Existe una condición por la que algunas máquinas podrían no detectar algunos dispositivos PCI correctamente, o podrían colgarse mientras detectan múltiples NICs en una sola máquina. Esto se debe al PCIBIOS, y tan sólo es necesario un pequeño ajuste para que funcione correctamente. Todo lo que hay que hacer es introducir la configuración de inicio y desactivar PCIBIOS. Mire un ejemplo:
boot> boot -c
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2002 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MDT 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel Pentium III (Coppermine) ("GenuineIntel" 686-class, 128KB L2 cache)
1 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SYS,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXS
R,SIMD
real mem = 267956224 (261676K)
avail mem = 243347456 (237644K)
using 3296 buffers containing 13500416 bytes (13184K) of memory
User Kernel Config
UKC> disable pcibios
UKC> quit
[... snip ...]
|
En cuanto haya terminado con esto, puede seguir las instrucciones de la sección sobre la compilación del núcleo para crear un nuevo núcleo y así no tendrá que preocuparse por esto en el futuro.
Veáse este documento.
No existe. Utilizamos un mecanismo diferente para obtener resultados similares, y que se llama Soft Updates. Por favor, lea la sección que se indica para obtener una información más detallada.
Muchos de los nuevos usuarios de OpenBSD experimentan un retraso de dos minutos en el ingreso cuando usan servicios como ssh(1), ftp(1), o telnet(1). También puede ocurrir cuando se usa una proxy, como ftp-proxy(8), o cuando se envía correo desde una estación de trabajo a través de sendmail(8).
Esto se debe casi siempre a un problema de DNS inverso. Las siglas DNS son de «Servicios de Nombres de Dominio», el sistema que usa Internet para convertir un nombre, como "www.openbsd.org", en una dirección IP numérica. Otra de las tareas de DNS es la de poder tomar una dirección numérica y convertirla de vuelta en un «nombre»; esto es «DNS inverso».
Para ofrecer un mejor ingreso, OpenBSD lleva a cabo una búsqueda de DNS inverso en cualquier máquina a la que se conecte por cualquiera de las muchas formas diferentes, como por ssh(1), ftp(1), telnet(1), sendmail(8), o ftp-proxy(8). Desafortunadamente, en algunos casos la máquina que lleva a cabo la conexión no tiene una entrada apropiada de DNS inversa.
Esto puede resultar bastante molesto. Por fortuna, existe una solución fácil.
El fichero /etc/hosts será algo parecido a esto:
::1 localhost.in.example.org localhost
127.0.0.1 localhost.in.example.org localhost
192.168.1.1 gw.in.example.org gw
192.168.1.20 scrappy.in.example.org scrappy
192.168.1.35 shadow.in.example.org shadow
|
El fichero resolv.conf será algo como esto:
search in.example.org
nameserver 24.2.68.33
nameserver 24.2.68.34
lookup file bind
|
Una objeción común a esto es «...pero, ¡yo uso DHCP para mi red interna! ¿Cómo puede configurar entonces mi fichero /etc/hosts?» Es fácil. Introduzca la líneas para todas las direcciones que su servidor de DHCP vaya a entregar, y cualquier dispositivo estático:
::1 localhost.in.example.org localhost
127.0.0.1 localhost.in.example.org localhost
192.168.1.1 gw.in.example.org gw
192.168.1.20 scrappy.in.example.org scrappy
192.168.1.35 shadow.in.example.org shadow
192.168.1.100 d100.in.example.org d100
192.168.1.101 d101.in.example.org d101
192.168.1.102 d102.in.example.org d102
[... etc ...]
192.168.1.198 d198.in.example.org d198
192.168.1.199 d199.in.example.org d199
|
En este caso se asume que tiene el rango de DHCP configurado desde 192.168.1.100 hasta 192.168.1.199, y las tres definiciones estáticas tal y como aparecen en la parte superior del fichero.
Si su pasarela debe usar DHCP para la configuración, es posible que se encuentre con un problema: dhclient(8) anulará su fichero /etc/resolv.conf cada vez que renueve la conexión, eliminando así la línea look file bind. Esto se puede solucionar incluyendo la línea look file bind en el fichero /etc/resolv.conf.tail.
Al escribir las páginas web actuales se ha puesto mucho cuidado para que se puedan ver con una gran variedad de navegadores modernos desde las versiones 4.0 en adelante. No queremos que estas páginas sean conformes con HTML4 o XHTML hasta que estemos seguros de que también se podrán ver con navegadores más antiguos; no es una prioridad. Aunque agradecemos cualquier nueva contribución en este respecto, creemos que es mejor usar el tiempo en escribir código o en documentar nuevos aspectos del sistema, en lugar de cambiar la páginas web para que sean conformes con nuevas especificaciones.
Al utilizar rdate(8) para sincronizar el reloj del sistema con un servidor de NTP es posible que exista un lapsus de tiempo de veintipico segundos con la definición horaria local.
Esto es debido a una diferencia entre el tiempo UTC (Tiempo Universal Coordinado, basado en observaciones astronómicas) y el tiempo TAI (Tiempo Atómico Internacional, basado en relojes atómicos). Para compensar las variaciones en la rotación de la tierra, se introducen «saltos de segundos» en el tiempo UTC, pero esto desajusta el tiempo TAI. Estos saltos de segundos son la causa de esta desincronización. Para más información sobre esto se puede buscar en Internet con las palabras clave "leap seconds UTC TAI".
Este problema es fácil de solucionar. En la mayoría de
países se puede obtener la hora correcta usando el
parámetro -c con la orden
rdate(8),
y usando una de las franjas horarias del directorio
/usr/share/zoneinfo/right/. Por ejemplo, si la
ubicación fuera Alemania, se podría usar estas
órdenes:
# cd /etc && ln -sf /usr/share/zoneinfo/right/CET localtime
# rdate -ncv ptbtime1.ptb.de
Las reglas pueden variar según el país.
[Índice de documentos] [Sección 7 - Controles de teclado y pantalla] [Sección 9 - Migrando desde un sistema Linux