Respuesta: En Unix (al menos Solaris y algunos Linux), mediante el comando

nscd -i hosts

o directamente reiniciando el demonio

/etc/init.d/nscd restart

(o stop | start dependiendo de las versiones).

En Windows, con el comando

ipconfig /flushdns

Por último, en OS X 10.4.x (Tiger), se borra mediante

lookupd -flushcache

y en 10.5.x (Leopard) con

dscacheutil -flushcache

Nota: Actualizada la receta el 26/10/09 para Leopard… un día de éstos comprobaré si funciona en Snow Leopard

Podemos modificar este timeout con:

# wcadmin add -p -a console session.timeout.value=minutos

y, a continuación, reiniciar el servicio mediante

# smcwebserver restart

Se puede comprobar que el cambio se ha realizado correctamente a través del comando

# wcadmin list -p

o, evidentemente, de forma empírica accediendo a Web Console y esperando los 15 minutos de rigor para ver si nos echa de la sesión .


w2003srv: C:\ level=full, 1 KB 00:00:12 2 files
w2003srv: E:\ level=full, 17 GB 22:11:56 16887 files
w2003srv: ASR:\ level=full, 1239 KB 00:05:28 12 files
w2003srv: SYSTEM DB:\ level=full, 11 MB 00:02:28 11 files
w2003srv: SYSTEM STATE:\ level=full, 175 MB 00:19:02 683 files
w2003srv: SYSTEM FILES:\ level=full, 457 MB 00:44:52 2646 files


El problema desaparece al actualizar la versión de NetWorker a la 7.3.3.

Para las copias de seguridad, la lista está en HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup; para la restauración, la clave es HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\KeysNotToRestore.

Origen:
LEGATO NetWorker Release 7.2 Administrator’s Guide, Microsoft Windows Version
Microsoft KB 233427

Tarea: Instalar en un nuevo servidor la última versión de Perl, junto con los módulos instalados en el antiguo equipo.

Hasta aquí todo correcto, pero… ¿qué modulos hay instalados en el antiguo servidor? El siguiente programita viene al rescate:


#!/usr/bin/perl -w

use ExtUtils::Installed;
my $instmod = ExtUtils::Installed->new();
foreach my $module ($instmod->modules()) {
    my $version = $instmod->version($module) || "Version not found";
    print "$module - $version\n";
}


Nota: ni soy el autor ni tengo idea de quién es, lo saqué de internés tiempo ha y, siguiendo mis costumbres, no tengo constancia de su origen.

# /opt/SUNWexplo/bin/explorer -w default,1280extended

Para evitar que pida la dirección y contraseña de la SC con cada comando que le envíe, el fichero de configuración a editar es el /etc/opt/SUNWexplo/1280input.txt.

Esta información es válida también para los Sun Fire V1280 y Netra 1280. Para estos modelos de servidores, la opción scextended de explorer no funciona, debido a diferencias de arquitectura.

Referencia: Document ID 76808 (requiere registro previo en SunSolve).

Tras revisar el Visor de sucesos en su equipo (Windows XP Professional SP2, en un dominio Windows Server 2003 SE, SP1), se observan los siguientes errores, aproximadamente al tiempo en que se producen los bloqueos de la cuenta:

Aplicación:

Sistema:

Solución: el problema resulta ser causado por algún problema en la entrada correspondiente al equipo en DNS. Supuestamente, Kerberos no podía autenticar el nombre del equipo, si bien en la consola DNS aparecían correctamente tanto el registro A como el PTR.

Tras borrar ambas entradas y recrearlas, el problema desaparece.

path hace referencia a una ubicación que no está disponible. Puede ser un disco duro en este
equipo o en una red. Compruebe que el disco está correctamente insertado, que está conectado
a Internet o a la red e inténtelo de nuevo. Si aún así no lo consigue, puede ser que la
información se haya movido a otra ubicación.

Solución: Al final, el problema ha resultado ser que la carpeta, cuyo nombre terminaba en un
espacio en blanco, había sido creada desde un Mac, accediendo al recurso compartido a través de
SMB. OS X permite nombres de ficheros y carpetas que finalicen en un punto o en un espacio en
blanco, mientras que Windows no los soporta. El problema desaparece tras renombrar la carpeta
desde OS X, eliminando el último carácter.

Investigando un poco (San Google al rescate), decidí que lo más sencillo era cambiar en destino los permisos, usando una característica de OS X llamada Folder Actions. Esta utilidad permite asociar un script (en AppleScript) a una carpeta, de manera que se ejecuta automáticamente al producirse cualquiera de una serie de eventos, por ejemplo al depositar un ítem en la carpeta (que al fin y al cabo era el que a mí me interesaba).

Al final, y teniendo de curso al administrador “titular” de todo_lo_relacionado_con_apple, pude encontrar el script ya programado en macOSXhints, tal y como sigue:


on adding folder items to this_folder after receiving added_items
  tell application "Finder"
    set fold_name to the name of this_folder
    try
      repeat with i from 1 to number of items in added_items
        set new_item to item i of added_items
        set the item_path to the quoted form of the POSIX path of new_item
        do shell script ("/bin/chmod -R +r " & item_path)
      end repeat
    end try
  end tell
end adding folder items to


que, al fin y al cabo, lo único que hace es ejecutar un chmod sobre el ítem depositado en la carpeta.

A raíz de este tema, y viendo la pinta que tiene AppleScript y sobre todo los Folder Scripts, me apetece aún más si cabe poner las manos encima de un Mac. Lo quiero yaaaaa …

Según la KB 555536 de Microsoft, se trata de un problema con la versión 2.2.29 de OpenLDAP (si bien en mi caso la versión no coincide exactamente). La solución es añadir al registro la clave HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\10.0\Outlook\LDAP y crear un nuevo valor DWORD, DisableVLVBrowsing, con el valor 1.

Para finalizar, como no, debe reiniciarse el equipo.