Kjell Wooding
<kjell@openbsd.org>
Updated:
$OpenBSD: upgrade-minifaq.html,v 1.81 2009/06/29 17:19:48 ajacoutot 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`/confLa 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 _pflogdcomo 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 /etcA 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 _syslogdcomo 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 installNó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 _spamdcomo 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/.
$OpenBSD: upgrade-minifaq.html,v 1.81 2009/06/29 17:19:48 ajacoutot Exp $
Copyright © 1998-2003, Kjell Wooding.
Envíe cualquier comentario, pregunta o sugerencia
(sólo en inglés, por favor) a
kjell@openbsd.org