Kjell Wooding
<kjell@openbsd.org>
Updated:
$OpenBSD: upgrade-minifaq.html,v 1.80 2004/01/01 23:30:28 horacio Exp $
Con esta guía minimalista se pretende aclarar los problemas más comunes que aparecen cuando se lleva a cabo una actualización entre versiones finales de OpenBSD (-release), o desde una versión final a una versión en desarrollo (-current). Aunque ya no sea un «mini-documento», todavía mantiene el nombre de Mini-FAQ por varios motivos. La información que trata sobre versiones más antiguas a las que aquí aparecen se puede encontrar en un documento separado.
Esta guía de actualización es para Usuarios Avanzados. Si se es un principiante o todavía no se tiene mucha experiencia en el manejo del compilador y las herramientas, no recomendamos la actualización mediante el código fuente. Es mejor intentar instalar una versión binaria final o preliminar, y después aplicar las instrucciones que se dan para la actualización de /etc.
1.1: Terminología. ¿Qué es -current?
¿Qué son los snapshots? ¿Qué es
-stable?
1.2: ¿Cuál es la forma más sencilla de actualizar a
-current?
1.3: No puedo encontrar ningún snapshot en el servidor
de FTP. ¿Dónde están?
1.4: ¿Cómo puedo obtenet el código fuente
más reciente?
1.5: Ya tengo el árbol de fuentes, ¿cómo lo
compilo?
1.6: 'make build' paró en la mitad del proceso, ¿tengo que
compilarlo todo de nuevo?
1.7: El proceso de compilación produce errores,
¿qué debo hacer?
1.8: ¿Hay algún procedimiento preestablecido para
actualizar el compilador gcc? versión más nueva.
1.9: ¿Cuál es la mejor forma de actualizar /etc,
/var, y /dev?
1.10: ¿Cómo hago para eliminar todo lo sobrante de la
compilar desde el árbol de fuentes?
1.11: ¿Es necesario ser el superusuario (root) para
ejecutar 'make build'?
1.12: ¿Por qué no veo ningún dispositivo nuevo?
1.13: ¿Hay alguna manera sencilla de llevar a cabo todos los
cambios en la jerarquía de archivos?
1.14: Después de actualizar, ps produce el siguiente
error: "proc size mismatch".
1.15: ¿Cómo puedo actualizar el sistema con la
última versión preliminar (snapshot)?
3.4.1: Cambios en los números menores del
dispositivo svnd
3.4.2: Nuevo usuario y grupo _pflogd
3.4.3: Clonación de interfaz
3.4.4: Nueva versión de join(1)
3.3.1: Soporte para W^X en i386
3.3.2: Cambio en la llamada al sistema mquery
3.3.3: i386 flag day, cambio en exe
addr/MAXDSIZ
3.3.4: Eliminación de la autenticación de
KerberosIV
3.3.4: Cambio en config
3.3.5: Uso de __attribute__((bounded)) en ciertas
funciones
3.3.6: Nuevo usuario y grupo _syslogd
3.3.7: Nuevo atributo de formato __kprintf__ en las
cabeceras del núcleo del sistema
3.2.1: Nuevo Perl
3.2.2: Nuevos grupos _radius, _token y _shadow
3.2.3: Cambios importantes en el compilador
3.2.4: Nuevo usuario y grupo _spamd
3.2.5: Alias para ipv6-icmp
3.2.6: Nuevo grupo _lkm
3.2.7: Nuevo libpthread
3.2.8: Cambios en el enlazador para las arquitecturas
ELF
3.2.9: Fusionados los cambios de /var/at y
crontab
3.1.1: Nuevos usuarios/grupos
3.1.2: Nuevo grupo para crontab(1) y at(1)
3.1.3: Nuevo Binutils
3.1.4: Nueva configuración para S/Key
3.1.5: Nuevos permisos para lp*
3.1.6: atrun(8) ya no es necesario
3.1.7: nat.conf fusionado con pf.conf
3.1.8: Nueva entrada en fbtab necesaria para
xdm
3.1.9: Uso de __attribute__((sentinel)) en ciertas
funciones
3.0.1: Soporte de nueva clave por mtree(8)
3.0.1: Eliminación de libdl en plataformas ELF
3.0.2: Nuevo marco de regresión
3.0.3: ficheros de configuración de ssh traspasados a
/etc/ssh/
2.9.1: Nuevos usuarios/grupos - proxy, smmsp y
popa3d
2.9.2: Nuevo filtro de paquetes IP
2.9.3: Cambios en make
2.9.4: Fallo de compilación a causa de KerberosV
2.9.5: La nueva versión de sendmail
2.9.6: Cambio en /etc/primes
La información sobre la actualización para las versiones 2.3 hasta la 2.8 de OpenBSD se encuentra en un documento separado.
Con anterioridad a OpenBSD 2.7, el desarrollo de OpenBSD tenía lugar desde un sólo árbol de fuentes sin ramificaciones. A partir de la versión 2.7 se introdujo una ramificación de parches.
Las versiones finales (-release) de OpenBSD se producen con intervalos aproximados de seis meses. Éstas se enumeran en un modo convencional (2.x, 3.x). La versión final actual de OpenBSD se indica al principio de este documento.
-current es la forma de abreviada de openbsd-current, la versiónd de desarrollo, se refiere a la versión de última hora en el árbol de fuentes del repositorio de CVS. Éste es el árbol que usan con más asiduidad los desarrolladores de OpenBSD. El árbol de -current contiene todo el código que está planeado para el lanzamiento de la siguiente versión final. De vez en cuando, algunos valientes abandonan las versiones oficiales y utilizan la versión de desarrollo, -current, generalmente para aprovechar funcionalidades que todavía no se han implementado en las versiones finales. Sin embargo, debido a su naturaleza de incertidumbre, la actualización a -current no es recomendable para usuarios no técnicos.
Entre una versión final y otra, creamos unas versiones preliminares ( snapshots). Éstas son revisiones instantáneas del árbol de fuentes de -current. Debido a que son un reflejo del estado actual de desarrollo, no se puede garantizar que estas versiones preliminares funcionen correctamente... ni siquiera que funcionen. Las versiones preliminares son bastante útiles cuando se está actualizando desde una versión final (o una versión de desarrollo más antigua) a la del árbol de desarrollo. Si el sistema del que se dispone es el de la versión de desarrollo, es muy recomendable seguir la lista de correo source-changes. Los mensajes de los cambios en el código suelen contener información valiosa sobre las últimas funcionalidades añadidas.
A partir de OpenBSD 2.7 se introdujo una versión estable (-stable). Ésta es una ramificación de la versión final (-release) base y cualquier otro parche o modificación importante (se consideran importantes los parches publicados en la página de erratas, además de otros que son obvios y simples pero que no merecen ser mencionados en dicha página).
El árbol de portes es una parte integral del sistema. Cada vez que se actualice el sistema, también hay que actualizar los portes, siguiendo las mismas reglas que existen para la actualización del resto de las partes; o sea, si el sistema es -stable los portes también deben ser -stable, y si el sistema es -current los portes sólo deben ser -current.
Debido a cambios en las bibliotecas de base, actualizar de una versión final (-release) a otra de desarrollo (-current) no siempre es fácil. La forma más difícil de actualizar a -current es actualizar primero a la revisión preliminar (snapshot) más reciente. Una vez el snapshot ha sido instalado, se pueden obtener los fuentes más recientes y compilarlos. Este procedimiento debería eliminar la mayoría de problemas con las bibliotecas y las herramientas necesarias.
Los snapshot se pueden retirar según se vayan quedando anticuados (o según dejen de ser relevantes). Si no hay ningún snapshot disponible, entonces se debe actualizar a la versión más reciente y compilar lo restante desde el código fuente.
Respuesta corta: http://www.openbsd.org/es/anoncvs.html
Por ejemplo, para obtener el árbol completo mediante CVS (usando
la shell ksh; para otras hay que sustituir export por
setenv):
# export CVSROOT=anoncvs@anoncvs.ca.openbsd.org:/cvs
# export CVS_RSH=/usr/bin/ssh
# cd /usr
# cvs -q get -P src
Nótese que con esto se obtendrá la versión de
desarrollo (-current). Para obtener otra versión, por
# cvs -q get -rOPENBSD_3_2 -P src
Hay unas instrucciones básicas en /usr/src/Makefile. Ésta es una versión ligeramente extendida.
Limpiar los ficheros objeto (/usr/obj/) antiguos.
Si se había creado un directorio /usr/obj separado,
hay que limpiarlo y reconstruir los enlaces simbólicos:
# rm -rf /usr/obj/*
# cd /usr/src
# make obj
Si hay que realizar este paso muchas veces, puede ser mucho más
rápido poner /usr/obj en la partición y usar
newfs en lugar de rm. Por ejemplo, lo que yo hago
es:
# umount /usr/obj
# newfs wd0h
# mount /usr/obj
# make obj
Si se está preocupado porque pueda haber ficheros objeto en el
árbol de fuentes, se puede hacer lo siguiente:
# cd /usr/src
# find . -type l -name obj | xargs rm
# make cleandir
# rm -rf /usr/obj/*
# make obj
Hay que llevar a cabo cualquier cambio de configuración específico para la versión. Por ejemplo, los usuarios de la versión 2.3 deben añadir el usuario y el grupo named antes de actualizar a la versión 2.4 o posterior. Es recomendable leer la sección específica para la versión concreta que se encuentra en este documento.
Es preciso asegurarse de que todos los directorios apropiados hayan
sido creados. Esto es muy importante cuando se actualiza desde
versiones más antiguas, pero a veces necesario en otros casos.
La forma más fácil de hacerlo es:
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
A continuación se compilará un nuevo núcleo
(kernel):
# cd /usr/src/sys/arch/`machine`/conf
La mayoría de usuarios utilizarán GENERIC:
# config GENERIC
# cd ../compile/GENERIC
NOTA: los usuarios a quienes les guste sufrir pueden
compilar un núcleo personalizado en lugar de usar el
núcleo GENERIC. En este caso es mejor empezar con GENERIC e ir
modificándolo. Para ello hay que hacer lo siguiente:
# cp GENERIC MYKERNEL
# vi MYKERNEL
(edite MYKERNEL según le convenga)
# config MYKERNEL
# cd ../compile/MYKERNEL
Finalmente, para todos:
# make clean && make depend && make
(sólo en la arquitectura arc) copie bsd.ecoff en su partición FAT
# cp /bsd /bsd.old && cp bsd /bsd
# chown root:wheel /bsd (si lo ha compilado como otro usuario)
(reinicie)
A continuación se compilará el sistema:
# cd /usr/src
# make build
/etc y /dev se actualizan a mano. Estos ficheros
no se actualizan de forma automática. Hay que escoger un
directorio con espacio suficiente para /, /dev,
/var, y /etc. En este ejemplo usaré
/home/newroot:
# mkdir /home/newroot
# export DESTDIR=/home/newroot
# cd /usr/src/etc && make distribution-etc-root-var
Ahora comparemos los ficheros en /home/newroot con sus
correspondientes ya instalados, y reemplazaremos o actualizaremos los
ficheros según sea necesario.
# rm -rf /home/newroot (cuando haya acabado)
Finalemente reiniciaremos el sistema para asegurarnos de que los nuevos ficheros en /etc sean los correctos.
Yo lo haría, pero si realmente quiere retomarlo desde el punto en
que se quedó, haga lo siguiente:
# cd /usr/src
# make -n build
De este modo le mostrará lo que 'make build' esté
haciendo. Por ejemplo, el mío dice:
(cd /usr/src/share/mk && make install)
(cd /usr/src/include; make prereq; make includes)
make cleandir
(cd /usr/src/lib && make depend && make && make install)
(cd /usr/src/gnu/lib && make depend && make && make install)
(cd /usr/src/kerberosIV/lib && make depend && make && make install)
(cd /usr/src/gnu/usr.bin/perl && make -f Makefile.bsd-wrapper config.sh &&
make -f Makefile.bsd-wrapper depend &&
make -f Makefile.bsd-wrapper perl.lib &&
make -f Makefile.bsd-wrapper install.lib)
make depend && make && make install
Para empezar desde donde se quedó, vuelva a invocar las órdenes desde el punto en donde se cortó la compilación.
Si tiene que realizar este procedimiento muchas veces, es posible que le convenga crear un nuevo objetivo en su fichero makefile. Sólo tiene que copiar la entrada para build (a build-noclean, por ejemplo), y eliminar la referencia make cleandir.
Si make build finaliza con un error, es muy posible que se deba a que no eliminó sus ficheros objeto antiguos antes de recompilar. Lea la sección 1.5 para más detalles sobre cómo limpiar esos ficheros.
Si está seguro de que su árbol está limpio de viejos restos, y aún así recibe un error de compilación, es que ha ocurrido una de las siguientes tres cosas:
Si ya ha probado todas las alternativas anteriores y su problema persiste durante más de un par de días, envíe un informe sobre su problema a misc@openbsd.org. Asegúrese de incluir los mensajes de error relevantes, así como cualquier peculiaridad de su configuración.
Debido a que la actualización de un compilador es como «el problema del huevo y la gallina», los cambios al compilador original del árbol requieren que se les preste algo más de atención. Por regla general se seguirá este procedimiento:
(... y sí, se compilará dos veces)
# rm -r /usr/obj/gnu/egcs/gcc/*
# cd /usr/src/gnu/egcs/gcc
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper obj
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
y a continuación ejecute un make build normal.
Puede acelerar este proceso usando el procedimiento de rutinas de
arranque (bootstrap):
# cd /usr/src/gnu/egcs/gcc
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper obj
# make -f Makefile.bsd-wrapper -DBOOTSTRAP
# make -f Makefile.bsd-wrapper -DBOOTSTRAP install
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
Respuesta corta: A mano.
Respuesta larga:
Como parte de la política de OpenBSD, el software en el árbol de cvs no modifica los ficheros en /etc de forma automática. Esto quiere decir que es siempre el administrador quien debe llevar a cabo las modificaciones necesarias a los ficheros de configuración. Las actualizaciones no constituyen una excepción. Para actualizar los ficheros en estos directorios, primero determine qué cambios ha sufrido los ficheros básicos de la distribución, y a continuación vuelva a aplicar esos cambios manualmente.
Por ejemplo, para ver los ficheros que han cambiado más
recientemente en el árbol, haga:
# cd /usr/src/etc
# ls -lt |more
Para ver todos los cambios en /etc entre versiones de OpenBSD
arbitrarias, puede usar CVS. Por
ejemplo, para ver los cambios acontecidos entre 3.1 y 3.2, haga:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_3_1 -rOPENBSD_3_2
Una vez que haya identificado los cambios, vuelva a aplicarlos a su árbol local, conservando cualquier configuración a nivel local que haya hecho Vd. anteriormente.
Algunos cambios que suelen ocurrir en /etc entre el paso de versiones, y que debe comprobar son:
Lo más importante que puede hacer es eliminar sus directorios
obj. Una forma de actualizar el código fuente y
eliminar cualquier resto de obj es:
# cd /usr/src
# cvs -q -d anoncvs@some.anon.server:/cvs up -Pd
# find . -type l -name obj | xargs rm
# make -k cleandir
# rm -rf /usr/obj/*
# make obj
Si todavía tiene algún problema, puede añadir las opciones -I ! -I CVS -I obj a sus actualizaciones por CVS. De este modo identificará cualquier resto adicional en su árbol de fuentes.
Aunque algunos pasos del proceso make build requieren los privilegios del superusuario (root), el proceso build incluye enlaces a la orden sudo(8) que hacen que este proceso sea relativamente sencillo.
Si su fichero /etc/sudoers está correctamente configurado, puede usar los enlaces de sudo de la siguiente forma:
El guión /dev/MAKEDEV no se actualiza de forma
automática como parte del proceso make build. Como
regla general, es recomendable copiar este guión desde su
árbol de fuentes cuando lleve a cabo una actualización, y
ejecutarlo a mano.
# cd /dev
# cp /usr/src/etc/etc.`machine`/MAKEDEV ./
# ./MAKEDEV all
De vez en cuando se añaden directorios y ficheros a, o se eliminan de, la jerarquía de archivos. Además también puede cambiar la información sobre permisos. Una forma fácil de asegurarse de que la jerarquía de archivos esté actualizada es usar la utilidad mtree(8).
Primero obtenga el código fuente más reciente, y luego
haga lo siguiente:
# cd /usr/src/etc/mtree
# install -c -o root -g wheel -m 600 special /etc/mtree
# install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
# mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
Ahora su jerarquía de archivos estará actualizada.
El modo de usuario y el núcleo del sistema están desincronizados. Los dos deben compilarse desde el mismo código fuente, ya que existen ciertas interdependencias entre ambos. Recompile el núcleo y el sistema con el mismo código para corregir este problema.
Y ya que ha cometido un error, ahora es el momento ideal para volver a leer todo este documento, y enterarse sobre otras cosas que pueda haber olvidado.
La instalación de una versión preliminar es una buena forma para estar al día. Queremos que se prueben las versiones preliminares, especialmente en su estado beta, para poder estar seguros de que la próxima versión final sea de una calidad superior. Y además es mucho menos difícil que recompilar todo el árbol de fuentes.
La forma más fácil de obtener la versión de desarrollo, -current, es con una imagen de arranque y prepararlo como se describe en el capítulo 4 de las preguntas frecuentes. Una vez que haya arrancado, hay que escoger la opción "(U)pgrade" para actualizar y seguir las instrucciones.
Hay varios modos de iniciar el programa de actualización. Generalmente, los métodos más fáciles son los de arranque desde disquete o desde CDROM, o copiar un fichero bsd.rd de la versión de desarrollo en el directorio raíz (/) y arrancar con ese núcleo en lugar de /bsd. Otras opciones incluyen arrancar a través de la red y arrancar desde una cinta. No todos estos métodos se encuentran disponibles para todas las arquitecturas; para más información véase las instrucciones de instalación correspondientes.
Nótese que el único medio de actualización seguro es el arranque desde un medio de instalación/actualización de los arriba descritos.
En todos los casos será necesario actualizar /etc, /var y /dev a mano.
Los números menores de los dispositivos svnd han cambiado; hay que ejecutar el fichero actualizado /dev/MAKEDEV después de instalar el nuevo núcleo:
# cp /usr/src/etc/etc.`machine`/MAKEDEV /dev
# cd /dev
# rm svnd* rsvnd*
# ./MAKEDEV vnd
El dæmon
pflogd(8)
ahora se ejecuta en modo separado de privilegio, y requiere un nuevo
usuario y grupo _pflogd. El grupo se genera ejecutando
# groupadd -g 74 _pflogd
como superusuario, y la entrada de usuario se añade mediante
vipw(8):
_pflogd:*:74:74::0:0:pflogd privsep:/var/empty:/sbin/nologin
Se han cambiado de lugar varios pseudo-dispositivos de red (como gif(4), lo(4), y tun(4)) para permitir el soporte de clonación, o sea la creación y destrucción sobre la marcha de dispositivos. Si el sistema depende de estas interfaces, hay que instalar una versión actualizada de ifconfig(8) y netstart(8) antes de reiniciar con el nuevo núcleo.
Primero hay que compilar e instalar el nuevo núcleo como de
costumbre, y luego
# cd /usr/src && make includes
# cd sbin/ifconfig
# make obj depend
# make
# make install
# cp /usr/src/etc/netstart /etc
A continuación hay que reiniciar la máquina y seguir
compilando el modo de usuario del sistema.
Se ha actualizado la orden
join(1) para el cumplimiento de las normativas POSIX al escribir
líneas no coincidentes. Como consecuencia, hay que actualizar
security(8):
# cp /usr/src/etc/security /etc
Para activar el soporte Writable xor eXecute en i386, OpenBSD/i386 ha cambiado desde el formato ejecutable a.out a ELF. La flexibilidad de ELF permite un mejor control sobre la capa ejecutable que permite el soporte de W^X. La compatibilidad con a.out sólo se encuentra disponible de forma limitada. Los binarios a.out estáticos funcionarán como antes, pero NO HABRÁ SOPORTE para binarios a.out dinámicos.
NO HABRÁ SOPORTE PARA ACTUALIZACIONES DE CÓDIGO FUENTE DESDE a.out A ELF. INSTALE UNA VERSIÓN PRELIMINAR (snapshot) y luego recompile el código. Esto es sólo para la plataforma i386, las otras arquitecturas no están afectadas por este cambio.
Los parámetros de la llamada al sistema mquery han cambiado para
que coincida con mmap(). Este cambio requiere que se actualice el
sistema en el orden correcto:
1. Compilar y arrancar un nuevo núcleo.
2. (cd /usr/src && sudo make includes)
3. (cd /usr/src/libexec/ld.so && make && sudo make install)
4. 'make build'
Sólo se usa mquery en la arquitectura i386; el resto de
arquitecturas no necesitan seguir este orden de compilación tan
estricto.
Para que se pueda cambiar MAXDSIZ de vuelta a 1G, la dirección de base de todos los ejecutables cambia de 0 a 0x1c000000. La combinación de estos cambios se requiere actualizar con una versión preliminar (snapshot). No hay soporte para actualizaciones desde el código fuente. Esto sólo afecta a la plataformas i386.
Se ha eliminado la autenticación basada en KerberosIV. Por lo tanto, es necesario eliminar todas las referencias a krb4 en /etc/login.conf.
Para mover swapgeneric.c se ha sido necesario un cambio en
config(8).
Antes de compilar un nuevo núcleo hay que compilar e instalar un
config(8) actualizado:
# cd /usr/src/usr.sbin/config
# make clean
# make obj
# make
# make install
Ahora, ya se puede usar config para la configuración del núcleo y ejecutar make depend en el directorio de compilación del núcleo como se explica en la sección 1.5.
Ahora se usa __attribute__((bounded)) para detectar argumentos
incorrectos para funciones que toman las medidas de los buffer
como uno de sus parámetros.
Es necesario recompilar gcc tal y como se indica en la
sección 1.8 de este documento antes de seguir
con make build.
Ahora el dæmon
syslogd(8)
se ejecuta en modo de privilegio separado, y requiere un nuevo usuario y
grupo _syslogd. Para añadir el grupo hay que ejecutar
# groupadd -g 73 _syslogd
como usuario root, y para añadir la entrada de usuario hay
que usar
vipw(8):
_syslogd:*:73:73::0:0:Syslog Daemon:/var/empty:/sbin/nologin
Ahora se usa un nuevo atributo de formato __kprintf__ en los archivos de
la cabeceras el núcleo para que gcc tenga conocimiento de las
extensiones de formato en el
printf(9)
del núcleo.
Hay que recompilar gcc de acuerdo con las instrucciones de la
sección 1.8 de este documento antes de
proceder a ejecutar make build. Sólo es necesario
recompilar gcc una vez desde el código fuente de -current
para que también tenga soporte para el atributo __bounded__
descrito en la sección 3.3.5.
Perl ha sido actualizado con la versión 5.8.0.
En Perl 5.8.0, el módulo API de XS ha cambiado debido a una
cambio de stdio a PerlIO (véase la
página del manual de perldelta para más
información). Esto quiere decir que cualquier módulo XS
(ficheros .so de perl) que haya instalado tendrá que ser
recompilado. Si aparece un error como Undefined symbol
"perl_get_sv", éste es el problema. Si los
únicos módulos que se han instalado son los que vienen
como paquetes precompilados o como portes del sistema, se pueden buscar
lo módulos XS en el sistema ejecutarndo:
# grep '\.so' /var/db/pkg/p5-*/+CONTENTS | cut -d: -f1 | sort -u
Y eliminar los módulos que producen el error con la orden pkg_delete -f y recompilarlos o reinstalarlos desde el árbol de portes.
Se han añadido varios grupos nuevos:
Antes de ejecutar make build hay que añadir estos
grupos y ajustar los permisos en algunos ficheros. Las siguientes
órdenes, ejecutadas como superusuario root, se
encargarán de todo esto:
# groupadd -g 63 _radius
# chgrp _radius /etc/raddb /etc/raddb/servers
# chmod g+x /etc/raddb
# chmod g+r /etc/raddb/servers
# groupadd -g 64 _token
# chgrp _token /etc/activ.db /etc/crypto.db /etc/snk.db
# chmod 0640 /etc/activ.db /etc/crypto.db /etc/snk.db
# groupadd -g 65 _shadow
# chgrp _shadow /etc/spwd.db
# chmod 0640 /etc/spwd.db
Los mensajes de error que puedan aparecer indicando que no se ha encontrado algún fichero no son importantes, simplemente son debidos a que no se ha configurado la autenticación de token o radius.
Se ha integrado la extensión para la protección de la pila propolice en gcc. Esto requiere de un escenario algo distinto:
# cd /usr/src
# make obj
Para las plataformas ELF (alpha, macppc, sparc, sparc64):
# cd /usr/src/libexec/ld.so
# make depend && make && make install
Para las plataformas a.out (amiga, hp300, i386, mac68k, mvme68k):
# cd /usr/src/gnu/usr.bin/ld/rtld
# make depend && make && make install
# cd /usr/src/include
# make prereq && make includes
# cd /usr/src/lib/libc
# make depend && make NOMAN=1 && make NOMAN=1 install
Nótese que si el compilador es demasiado viejo, no podrá
compilar libc. En ese caso será necesaria una
actualización binaria con una versión preliminar.
Se ha añadido un nuevo usuario y un nuevo grupo _spamd para el
dæmon
spamd(8).
Hay que añadir la entrada correspondiente al nuevo grupo con la
orden groupadd(8):
# groupadd -g 62 _spamd
como superusuario root, y la correspondiente al usuario editando
el fichero de contraseñas con
vipw(8):
_spamd:*:62:62::0:0:Spam daemon:/var/empty:/sbin/nologin
Se ha añadido un nuevo alias para ipv6-icmp, icmp6, a
/etc/protocols. Si se desea usar el alias icmp6
(usado en las pruebas de regresión de
pfctl(8)),
hay que modificar antes la línea ipv6-icmp en
/etc/protocols, añadiendo la clave icmp6 antes
del signo #. La línea debe quedar como sigue:
ipv6-icmp 58 IPv6-ICMP icmp6 # ICMP for IPv6
El grupo _lkm controla el acceso a /dev/lkm. Ahora, modstat(8) es setgid _lkm.
Se debe añadir este grupo y adaptar los permisos en
/dev/lkm antes de invocar un make build. Para ello
hay que usar las siguientes órdenes como superusuario
root:
# groupadd -g 61 _lkm
# chgrp _lkm /dev/lkm
libc_r y libnpthread han sido eliminados y sustituidos por libpthread. Los programas que dependan de esto todavía se deben compilar usando la opción -pthread; el compilador hará lo correcto.
Antes de eliminar libc_r y libnpthread, hay que recompilar las aplicaciones que dependan de éstos, usando libpthread. La secuencia que se recomienda es:
compilar gcc de acuerdo con la sección 1.8.
recompilar el sistema de acuerdo con la sección 1.5.
recompilar todos los portes que usen pthreads.
eliminar las bibliotecas que ya no se utilicen:
# rm /usr/lib/libc_r* /usr/lib/libnpthread*
Binutils/ld han cambiado para introducir una nueva funcionalidad de seguridad en los ejecutables ELF. En lugar de permitir que el enlazador marque la sección de datos de los ejecutables y las bibliotecas compartidas como ejecutables, se ha cambiado la composición para marcar sólo las secciones apropiadas de la imagen del programa como ejecutables. Este cambio sólo afecta a las arquitecturas basadas en ELF: alpha, sparc, sparc64, macppc.
Se recomienda recompilar binutils antes que el resto del sistema.
# cd /usr/src/gnu/usr.bin/binutils
# make -f Makefile.bsd-wrapper cleandir
# make -f Makefile.bsd-wrapper obj
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
Y luego recompilar el sistema de acuerdo con la sección 1.5.
Ahora que at se ha integrado en cron, el contenido de /var/at se ha fusionado en /var/cron. Además, ha cambiado el nombre de los ficheros allow y deny de cron por cron.allow y cron.deny para el cumplimiento de las normativas de POSIX y para su consistencia con los ficheros at.allow y at.deny.
Primero hay que recomponer el sistema de acuerdo con la sección
1.5, y luego pasar todos los ficheros y reiniciar
cron como sigue:
# mv /var/at/* /var/cron
# mv /var/cron/jobs /var/cron/atjobs
# mv /var/cron/allow /var/cron/cron.allow
# mv /var/cron/deny /var/cron/cron.deny
# rm -rf /var/at
# kill `cat /var/run/cron.pid`
# /usr/sbin/cron
No hay que hacer caso de los avisos sobre ficheros allow o deny que falten, ya que no todos son parte de la instalación predeterminada.
Si todavía no se dispone de un fichero cron.deny (no se
incluía en la instalación de versiones de OpenBSD
anteriores a la 3.3), es necesario tener uno para poder ejecutar
crontab con un usuario que no sea el superusuario.
# install -c -o root -g crontab -m 660 /dev/null /var/cron/cron.deny
Para el soporte de
authpf(8)
se requiere un nuevo grupo. Además, para el soporte de la nueva
funcionalidad de separación de privilegios de
sshd(8),
se ha añadido al sistema un nuevo usuario y grupo con el nombre
de sshd. Se han añadido más usuarios nuevos para
servicios del sistema; éstos llevan el prefijo "_".
Para añadirlos use
vipw(8):
sshd:*:27:27::0:0:sshd privsep:/var/empty:/sbin/nologin
_portmap:*:28:28::0:0:portmap:/var/empty:/sbin/nologin
_identd:*:29:29::0:0:identd:/var/empty:/sbin/nologin
_rstatd:*:30:30::0:0:rpc.rstatd:/var/empty:/sbin/nologin
_rusersd:*:32:32::0:0:rpc.rusersd:/var/empty:/sbin/nologin
_fingerd:*:33:33::0:0:fingerd:/var/empty:/sbin/nologin
_x11:*:35:35::0:0:X server:/var/empty:/sbin/nologin
Y añada lo siguiente al fichero /etc/group:
sshd:*:27:
_portmap:*:28:
_identd:*:29:
_rstatd:*:30:
_rusersd:*:32:
_fingerd:*:33:
_sshagnt:*:34:
_x11:*:35:
authpf:*:72:
La órdenes crontab(1) y at(1) ya no son setuid root, ahora son setgid crontab.
Antes de llevar a cabo la ejecución de make build para
compilar el sistema, tiene que añadir el grupo crontab.
Aсada una línea como la siguiente en el fichero
/etc/group:
crontab:*:66:
La ejecución de make build actualizará algunos
permisos, pero no todos. Después de que acabe make
build, debe ejecutar lo siguiente a mano (se asume que el
intérprete es /bin/csh):
# chgrp crontab /var/at/at.{allow,deny} /var/cron/{allow,deny}
# chmod 0640 /var/at/at.{allow,deny} /var/cron/{allow,deny}
# foreach f ( /var/cron/tabs/* )
set u=`basename $f`
chown $u:crontab $f
end
Nótese que probablemente no estarán todos los ficheros allow/deny; esto no es un problema.
Un nuevo binutils (2.11.2) ha sido añadido al
árbol de fuentes, y requiere una biblioteca libiberty
actualizada. Para compilar esta biblioteca siga los siguientes pasos:
# cd /usr/src/gnu/egcs/libiberty
# make -f Makefile.bsd-wrapper cleandir
# make -f Makefile.bsd-wrapper obj
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
La vieja base de datos de S/Key, /etc/skeykeys, ha sido
sustituida por un directorio, /etc/skey, en el que cada entrada
es un fichero individual propiedad del usuario al que describe. Puede
convertir /etc/skeykeys al nuevo formato ejecutando (como
superusuario):
# skeyinit -C
# mv /etc/skeykeys /etc/skeykeys.OLD
Nótese que cualquier programa que utilice S/Key directamente tendrá que ser recompilado.
Ahora, los directorios de cola que usa lpd deben tener permiso de
escritura para el grupo daemon, para que lpr pueda poner ficheros en la
cola. Además, los propietarios de los ficheros de los
directorios de cola deben ser el usuario y grupo daemon. Esto se puede
aplicar del modo siguiente:
# find /var/spool/output /var/spool/lpd -type d \
-execdir chgrp daemon {} \; -execdir chmod g+rwx {} \;
# find /var/spool/output /var/spool/lpd -type f \
-execdir chown daemon:daemon {} \;
La orden
atrun(8)
ya no es necesaria. Esta funcionalidad ha sido incorporada en
cron(8).
Hay que eliminar el guión /usr/libexec/atrun del
crontab del usuario root, ejecutando la siguiente
orden como superusuario:
# crontab -e
También pueden eliminarse /usr/libexec/atrun, /usr/share/man/cat8/atrun.0 y el directorio /var/at/spool.
/etc/nat.conf se ha fusionado con /etc/pf.conf. Hay que introducir la reglas de NAT en el fichero pf.conf después de las reglas de limpieza y antes de las reglas de filtrado.
pfctl(8) tiene una nueva opción para cargar los juegos de reglas, -f, y las opciones -R y -N ahora tienen nuevos significados. Es necesario leer la página del manual y actualizar el fichero de configuración /etc/rc.
login(1)
necesita cambiar el propietario de /dev/wsmouse al nuevo
usuario _x11 que es utilizado por xdm para la revocación
de privilegios en muchas arquitecturas. El cambio necesario en
/etc/fbtab es dependiente de la arquitectura. El fichero se
genera mediante el siguiente proceso (se asume que el código
fuente se encuentraa en /usr/src):
# cat /usr/src/etc/fbtab.head > /etc/fbtab
# cat /usr/src/etc/etc.`uname -m`/fbtab >> /etc/fbtab
# cat /usr/src/etc/fbtab.tail >> /etc/fbtab
Si se han hecho cambios personalizados en /etc/fbtab, hay que volverlos a incluir a mano en el nuevo fichero.
Ahora, __attribute__((sentinel)) se utiliza para avisar cuando se usen
sin un puntero NULL de terminación ciertas funciones de
exec(3).
Es necesario recomponer gcc de acuerdo con la
sección 1.8 de este documento antes de
proceder con make build.
Debe instalar una nueva versión de la utilidad
mtree(8)
antes de que funcione make build.
# cd /usr/src/usr.sbin/mtree
# make cleandir
# make obj
# make depend
# make
# make install
Las plataformas basadas en ELF (alpha, macppc y sparc64) ya no usan
libdl. La actualización desde un sistema libdl a otro
no libdl se hará mejor siguiendo estos pasos:
Recompile su sistema:
# cd /usr/src
# make build
Si make build se completó con éxito, puede
continuar y eliminar libdl. Nótese que los paquetes que
se hayan enlazado contra libdl deberían ser reinstalados
depués de eliminarlo. Si no está preparado para hacerlo,
puede saltarse este paso de momento. Las versiones preliminares
(snapshots) traerán paquetes correctos.
# rm -f /usr/lib/libdl.* /usr/lib/libdl_pic.a
Una vez eliminado libdl, regenere el caché de sus
bibliotecas compartidas:
# ldconfig -R
Se ha introducido una nueva infraestructura para pruebas de
regresión, y se ha añadido bsd.regress.mk.
Tendrá que instalarlo antes de ejecutar make obj.
# cd /usr/src/share/mk
# make install
Primero debe crear el directorio /etc/ssh/ (véase la sección 1.13).
A continuación recompile el sistema:
# cd /usr/src
# make build
Pase los ficheros /etc/ssh*_* al nuevo directorio
/etc/ssh/:
# cd /etc
# mv ssh*_* ssh/
Tendrá que cambiar sus guiones de ejecución (scripts) de rc para que reflejen también estos cambios.
Y actualizar cualquier línea con HostKey en el fichero
sshd_config para que reflejen la nueva ubicación. Por
ejemplo,
HostKey /etc/ssh_host_key
debe cambiarse a
HostKey /etc/ssh/ssh_host_key
Con la adición del nuevo paquete de filtros de IP
pf(4)
y su suite
ftp-proxy(8),
se añadieron un nuevo usuario y grupo proxy al sistema.
Para el soporte de éste debe añadir la siguiente entrada
de usuario usando
vipw(8):
proxy:*:71:71::0:0:Proxy Services:/nonexistent:/sbin/nologin
También añada también el grupo proxy a
/etc/group:
proxy:*:71:
Además, como parte de la actualización a Sendmail 8.12,
sendmail ya no tiene el bit setuid root. Un nuevo usuario y
grupo, smmsp, han sido añadidos al sistema.
Añada una línea como la siguiente a /etc/group:
smmsp:*:25:
A continuación ejecute
vipw(8)
y añada la siguiente línea para el usuario smmsp:
smmsp:*:25:25::0:0:Sendmail Message Submission Program:/nonexistent:/sbin/nologin
Asegúrese de que esta línea aparezca antes de cualquier otra línea de la configuración sobre yp(8).
Para finalizar, también se añadieron un nuevo usuario y
grupo para el servidor popa3d de Solar Designer, que ahora
forma parte integral del sistema. Añadia la siguiente
línea a /etc/group:
popa3d:*:26:
y usando
vipw(8),
añada
popa3d:*:26:26::0:0:POP3 server:/var/empty:/sbin/nologin
El paquete de cortafuegos IPF que había formado parte de las versiones anteriores de OpenBSD ha sido reemplazado por una suite de cortafuegos completamente nueva, llamada pf(4). Como resultado, es necesario llevar a cabo unos cuantos cambios.
Primero, pf depende de un nuevo fichero de dispositivo. Para
asegurarse de que se crea este dispositivo especial haga la siguiente:
# cd /dev
# cp /usr/src/etc/etc.`machine`/MAKEDEV ./
# ./MAKEDEV all
Segundo, han acontecido algunos cambios en el sistema de archivos. Los
siguientes binarios han sido reemplazados:
ANTIGUOS (IPF):
/sbin/ipf /sbin/ipfstat /sbin/ipnat /usr/sbin/ipfs
/usr/sbin/ipftest /usr/sbin/ipmon /usr/sbin/ipresend
/usr/sbin/ipsend /usr/sbin/iptest
NUEVOS (PF):
/sbin/pfctl
/usr/libexec/ftp-proxy
De igual modo, para los dispositivos (/dev):
ANTIGUOS (IPF): /dev/ipl /dev/ipnat /dev/ipstate /dev/ipauth
NUEVOS (PF): /dev/pf
Y finalmente los ficheros de configuración del filtro:
ANTIGUOS (IPF): /etc/ipf.rules /etc/ipnat.rules
NUEVOS (PF): /etc/pf.conf /etc/nat.conf
Puede borrar los ficheros de configuración antiguos de ipfilter:
# rm -rf /usr/share/ipf
Se ha añadido un mecanismo para activar pf de forma segura a los ficheros /etc/rc y /etc/rc.conf. Es necesario actualizar estos ficheros para que incluyan el nuevo mecanismo de enganche. Si desea activar pf, configure PF=YES en /etc/rc.conf.
Se han producido algunos cambios en
make(1)
y en sus ficheros de datos, que pueden originar dificultades en el
proceso de compilación e instalación. Estos cambios
suelen manifestarse con errores de bsd.own.mk durante la
compilación e instalación. Para evitarlo, actualice antes
los ficheros de datos: Antes que nada actualice los ficheros de datos:
# cd /usr/src/share/mk
# make install
y entonces compile e installe el nuevo make:
# cd /usr/src/usr.bin/make
# make clean && make obj && make depend && make
# make install
Antes de intentar compilar todo el sistema, debe compilar KerberosV:
Primero, hay un nuevo directorio de configuración de KerberosV en /etc. Si todavía no lo ha hecho, use el procedimiento de mtree(8) descrito en section 1.13 para crearlo.
Ahora, compile KerberosV:
# cd /usr/src/kerberosV
# make obj
# cd lib/roken
# make
# cd ../../usr.bin/asn1_compile
# make
# make install
También puede ser necesario actualizar /etc/login.conf para indicar que el nombre del fichero /usr/libexec/auth/login_krb-or-pwd ahora es login_krb4-or-pwd.
sendmail(8) ha sido actualizado a la versión 8.12. Como a partir de esta versión, sendmail ya no ejecuta setuid root, existen algunos cambios muy significativos.
Añada lo siguiente al fichero
crontab(1)
de root. Esto es necesario dado que sendmail ya no ejecuta
setuid root, y necesitará esta entrada para hacer parte
de su función:
# sendmail clientmqueue runner
*/30 * * * * /usr/sbin/sendmail -L sm-msp-queue -Ac -q
Actualice sendmail:
# cd /usr/src/gnu/usr.sbin/sendmail
# make clean && make obj && make depend && make && make install
Nota: los ficheros submit.cf y localhost.cf se han instalado en su directorio /etc/mail. El primero de éstos, submit.cf (al que la documentación actual de sendmail llama el fichero de configuración del «cliente»), lo utilizan los agentes de usuario de correo que quieren enviar correo de forma local para su reparto por medio de sendmail. Debido a los cambios en los permisos que se han descrito anteriormente, para esto no es necesario disponer de privilegios de superusuario: el identificador de grupo del binario ejecutable de sendmail se configura con smmsp. El segundo fichero, localhost.cf, es una particularidad de OpenBSD que ejecuta sendmail sólo para escuchar en la interfaz del anfitrión local para aceptar el correo que provenga del anfitrión sin aceptar conexiones provenientes de la red (si utiliza, por ejemplo, smtpd(8) para escuchar por el puerto SMTP de su interfaz externa, es casi seguro que le interesará usar esta opción). Puede conocer más detalles al respecto leyendo en fichero SECURITY que encontrará en /usr/src/gnu/usr.sbin/sendmail/sendmail.
Es muy recomendable que regenere y actualice sus ficheros de configuración de sendmail en /etc/mail. Puede encontrar algunos ficheros de configuración funcionales en /usr/share/sendmail/cf. Nótese que el fichero localhost.cf se genera desde openbsd-localhost.mc.
Si utiliza sendmail sin la opción -bd en
/etc/rc.conf, que es como se usa en la configuración de
la instalación predeterminada, tendrá que usar
localhost.cf. Edite el fichero rc.conf para
añadir lo siguiente:
# For normal use: "-L sm-mta -bd -q30m"
sendmail_flags="-L sm-mta -C/etc/mail/localhost.cf -bd -q30m"
En cuanto esté preparado su fichero de configuración,
use kill(1)
para acabar con el proceso existente de sendmail:
kill `sed 1q /var/run/sendmail.pid`
y reinicie el nuevo sendmail con las opciones apropiadas, como por
ejemplo:
/usr/sbin/sendmail -L sm-mta -bd -q30m
para una configuración que acepte correo desde el exterior,
o:
/usr/sbin/sendmail -L sm-mta -C/etc/mail/localhost.cf -bd -q30m
para una configuración que sólo acepte correo interno.
Nota: el indicador -bd es ahora necesario en ambos casos.
El nuevo sendmail debería funcionar a partir de este momento.
El nombre del fichero /etc/primes es ahora /etc/moduli. Sólo tiene que copiarlo desde su antigua ubicación o desde /usr/src/etc/.
Originally [OpenBSD: upgrade-minifaq.html,v 1.182 ]
$Translation: upgrade-minifaq.html,v 1.86 2003/12/30 12:04:40 horacio Exp $
$OpenBSD: upgrade-minifaq.html,v 1.80 2004/01/01 23:30:28 horacio Exp $
Copyright © 1998-2003, Kjell Wooding.
Envíe cualquier comentario, pregunta o sugerencia
(sólo en inglés, por favor) a
kjell@openbsd.org