Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 25 de Julio de 2009 - Sábado
Tengo un problema con ZFS: el directorio "/var/ntp/ntpstats/" lo tengo bajo ZFS, pero el montaje de las particiones ZFS no es una condición en el lanzamiento del demonio NTP. Así que, cuando tienes mala suerte, el demonio NTP puede arrancar e intentar grabar un fichero de log antes de que la partición ZFS esté activada. En ese caso, NTP creará un fichero de log nuevo en la partición UFS subyacente. Tendremos un error cuando se intente montar la partición ZFS, porque el directorio sobre el que se monta no está vacío (tiene el fichero de log recién creado).
El resultado es que el sistema no arranca correctamente, ya que el intento de montar todas las particiones locales falla, y muchos otros servicios dependen de que ese proceso se complete.
Personalmente considero que se trata de un bug de Solaris 10, desencadenado porque tengo la partición "/var/ntp/ntpstats/" bajo ZFS. Soy así de especial :-)
¿Soluciones?. La más obvia es no separar dicho directorio en otra partición, pero tengo mis razones. La solución correcta es que el montaje ZFS sea una dependencia que debe cumplirse antes de que se pueda lanzar NTP.
Es de señalar que esto dejará de ser un problema cuando Solaris 10 permita arrancar desde ZFS (¿para finales de 2008, quizá?), ya que en ese momento todo el disco será ZFS, sin particiones UFS subyacentes. Mientras tanto, tenemos que hacer algo.
Voy a añadir una dependencia al lanzamiento de NTP, para que el sistema lo retenga hasta que el montaje ZFS se haya completado. Lo normal sería desactivar el NTP del sistema operativo e instalar una configuración personalizada para el mismo, de forma que sobreviviese actualizaciones del sistema, parches, etc. Pero como entiendo que este "chanchullo" solo tiene una utilidad temporal (hasta que Solaris permita arrancar desde ZFS y yo jubile UFS), prefiero alterar la configuración del sistema aunque se pierda cuando lo actualice.
El primer lugar hay que ver cuál es la situación actual:
[root@tesalia z]# svcs -l ntp fmri svc:/network/ntp:default name Network Time Protocol (NTP) enabled true state online next_state none state_time Wed Mar 19 21:33:21 2008 logfile /var/svc/log/network-ntp:default.log restarter svc:/system/svc/restarter:default contract_id 34 dependency require_all/error file://localhost/usr/sbin/ntpq (online) file://localhost/usr/sbin/ntpdate (online) dependency require_any/error svc:/network/service (online)
Vemos que entre las dependencias no está el montaje de las particiones locales. Vamos a añadirlo.
El primer paso será exportar la configuración actual (manifiesto), para modificarla:
[root@tesalia z]# svccfg export svc:/network/ntp >manifiesto
Ahora cargamos el manifiesto en nuestro editor favorito. Añadimos lo siguiente, junto con el resto de dependencias:
<dependency name='particiones' grouping='require_all' restart_on='error' type='service'> <service_fmri value='svc:/system/filesystem/local'/> </dependency>
Reimportamos el manifiesto:
[root@tesalia z]# svccfg import manifiesto
Listamos la configuración nueva:
[root@tesalia z]# svcs -l ntp fmri svc:/network/ntp:default name Network Time Protocol (NTP) enabled true state online next_state none state_time Wed Mar 26 15:41:33 2008 logfile /var/svc/log/network-ntp:default.log restarter svc:/system/svc/restarter:default contract_id 34 dependency require_all/error file://localhost/usr/sbin/ntpq (online) file://localhost/usr/sbin/ntpdate (online) dependency require_any/error svc:/network/service (online) dependency require_all/error svc:/system/filesystem/local (online)
Problema solucionado.
Las soluciones temporales se hacen permanentes
Ha pasado más de un año desde la primera versión de esta página. Ya tengo mi sistema montado con ZFS "root"/"boot", pero sigo manteniendo "/var/ntp/ntpstats/" como un "dataset" separado. Me interesa mantenerlo así.
El problema ha surgido hoy, que he instalado parches en Solaris y la máquina no ha arrancado correctamente... porque uno de los parches era una actualización del "manifest" SMF del NTP, que deshace los cambios que describo en esta página.
Lo obvio, entonces, es hacer las cosas bien: desactivar el SMF NTP de Solaris, copiar su configuración, adaptarla a mis necesidades y reactivar mi versión. De esta forma, si Sun vuelve a actualizarlo no pasa nada, porque está marcado como "disabled", y mi versión es la que sigue mandando.
Lo único que tendré que hacer es, de año en año, comparar mi "manifesto" con el del sistema, y adoptar cualquier cambio que se haya hecho y que me venga bien.
La cosa queda así:
[root@tesalia svc]# svcs -l ntp fmri svc:/jcea/ntp:default name Network Time Protocol (NTP) enabled true state online next_state none state_time Sat Jul 25 03:50:46 2009 logfile /var/svc/log/jcea-ntp:default.log restarter svc:/system/svc/restarter:default contract_id 205 dependency require_all/error file://localhost/usr/sbin/ntpq (online) file://localhost/usr/sbin/ntpdate (online) dependency require_any/error svc:/network/service (online) dependency require_all/error svc:/system/filesystem/local (online) dependency optional_all/error svc:/milestone/name-services (online) fmri svc:/network/ntp:default name Network Time Protocol (NTP) enabled false state disabled next_state none state_time Sat Jul 25 03:27:43 2009 restarter svc:/system/svc/restarter:default dependency require_all/error file://localhost/usr/sbin/ntpq (online) file://localhost/usr/sbin/ntpdate (online) dependency require_any/error svc:/network/service (online) dependency optional_all/error svc:/milestone/name-services (online)
Reinicio y todo funciona como debe.
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
