Category: El día a día

Problemas con la impresión en local

10 septiembre 2014

Las máquinas facturacion1 y extranjero se han quedado sin poder imprimir en la red esta mañana. Después de varios reintentos he conseguido que vuelvan a aparecer las impresoras pero no estoy seguro de qué lo ha causado y cómo se ha arreglado.

El problema se encuentra en que cups, el servidor local de impresión, no puede acceder a ciertos puertos en la red para escuchar qué impresoras se ofrecen. He reiniciado los servicios rpcbind, avahi-daemon y cups con varias combinaciones hasta que lo he conseguido.

Sí que he visto en los registros mensajes que hacía tiempo que no veía. Concretamente algo como:

Sep 10 09:49:06 extranjero rpc.idmapd[1783]: nss_getpwnam: name ‘alfredo@venexma.net’ does not map into domain ‘localdomain’

Y es algo que he visto antes pero no consigo saber dónde. Algún detalle de la última instalación, supongo.

 

Archivos robots.txt

10 septiembre 2014

Estudiando las estadísticas de acceso a nuestros servidores me encuentro con que se hacen muchísimas peticiones hacia los archivos robots.txt, que no existen, y he pensado que sería bueno tener algunos.

He creado un archivo de este tipo -empleando una herramienta externa por pura pereza- para los dominios admin.venexma.com y static.venexma.com. Los he instalado a mano tras añadirlos al paquete venexma-albion.

Latch integrado en el blog

9 septiembre 2014

Para controlar el acceso con mi usuario (victor) a este blog he integrado la herramienta Latch sin prácticamente ningún problema.

Ahora puedo, desde el móvil,. monitorizar y controlar el acceso a este sitio 🙂

 

 

Arreglando detallitos: el blog, actualizaciones y estadísticas web

9 septiembre 2014

Hoy, entre otras cosas, me propongo reparar tres aspectos de la administración del sistema que no funcionan: la vista del blog de desarrollo desde la intranet, el usuario especial actualizador con el que pongo al día los sistemas y desatascar el analizador de registros del servidor web de venexma.es (y otros) que se hace un lío con registros antiguos.

Navegación interna por el blog de desarrollo

Tan sencillo como activar las reglas de reescritura de direcciones en el archivo htaccess correspondiente. En mi caso, y creo que es norma en Debian, este archivo se sitúa en /etc/wordpress/.htaccess, como enlace procedente de /usr/share/wordpress/.htaccess.

La estrofa es la siguiente:

[apache]

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

[/apache]

Usuario especial para actualizar máquinas

En todos los sistemas existe un usuario específico para actualizarlas en remoto y en bloque. Se llama actualizador, tiene la misma contraseña en todas las máquinas (es lo más cómodo, no lo más seguro) y accede desde un punto central (sigfrido) a cada una empleando una clave pública.

Hasta ahora no lo he automatizado por pura pereza, pero cada vez que cambio los componentes de una máquina la conexión se pierde y es necesario volver a hacer lo mismo.

Escribo una pequeña lista de cosas que hacer para poner en marcha una máquina como nodo del mecanismo de actualizaciones remotas:

  1. Instalar el paquete apt-dater-host.
  2. Activar configuración de sudo en el archivo /etc/sudoers.d/apt-dater-host.
  3. Crear un usuario llamado actualizador dentro del grupo adm y con la contraseña habitual registrada en https://admin.venexma.net/passwords.
  4. Accedemos al servidor central (sigfrido) con el usuario actualizador y desde allí copiamos la clave pública en la máquina que estamos configurando. Empleamos para ello ssh-copy-id sin darle más indicaciones que el destino.
  5. Testear ésto último entrando vía ssh a la máquina en configuración desde el servidor. Y cuidado porque es posible que ni así se consiga dado que la dirección IP, la identificación de la máquina o combinaciones de ambas hayan cambiado y sea necesario retocar el archivo ~/.ssh/known_hosts del usuario actualizador en sigfrido.

Martes, 9 de Septiembre

Obviamente ayer no me dio tiempo a completar lo que me proponía, así que esta mañana he tenido trabajo pendiente.

Registros de acceso al servidor web no válidos

Todo el mecanismo de creación de estadísticas web (y disponible aquí) tenía un fallo que impedía que funcionase y, de paso, me inundaba el buzón con mensajes de error. Resulta que los registros generados por el servidor web en venexma.es deben estar en un formato concreto. Si no es así awstats no puede realizar su trabajo y aborta todo el proceso.

La solución ha consistido en efectuar un filtrado previo de los registros para aceptar únicamente aquellos que tienen el formato adecuado. Dado que la configuración de awstats es flexible he creado un programa (incluído en el paquete venexma-sigfrido) que se encarga de este trabajo y de llamar a la herramienta correspondiente.

La configuración de cada dominio para las estadísiticas incluye una línea como la que sigue:

[ini]

LogFile=»/usr/bin/weblog2awstats dominio | »

[/ini]

reemplazando dominio por aquél que queremos procesar (static.venexma.com,venexma.com,…).

 

 

 

Declaraciones 349 e Intrastat de Agosto

3 septiembre 2014

Por lo que hemos podido ver Luismi y yo el 349 de Julio se declaró el 1 de Agosto; asumimos que fue alguien de Vicente Gabaldón puesto que le pasamos el archivo generado por el programa Informativas de la AEAT.

Por nuestra parte hemos creado dos declaraciones de Intrastat sin operaciones para el mes de vacaciones.

Añadiendo software encontrado por ahí

3 septiembre 2014

Y es que algunos paquetes prácticamente desaparecen de la red y como son imprescindibles para determinados usos, como los controladores de impresión especialitos, me veo en la necesidad de situarlo en algún sitio al que tengamos un acceso sencillo.

¿ Qué mejor que utilizar nuestro repositorio local de paquetes Debian ? Acabo de añadir una rama nueva extra en la que he situado todos aquellos paquetes que he ido recolectando. El manifiesto está en extra/Packages y lo he creado con dpkg-scanpackages cómodamente.

El paquete venexma-workstation, que configura cada máquina al nivel más bajo, se ha actualizado para incluirlo y por ahora funciona bien.

Copias de seguridad de máquinas virtuales

3 septiembre 2014

Con el empleo de las herramientas libvirt en el servidor sigfrido tenemos ahora mucho más fácil la realización de copias de seguridad de las máquinas virtuales, especialmente aquellas tan delicadas como helena y su nuevo clon troya.

Ambas emplean imágenes literales de los discos físicos donde originalmente residían y por ello no hay una forma sencilla de crear instantáneas de los mismos (snapshots). Se me ha ocurrido una idea que puede funcionar y sobre la que estoy trabajando hoy.

Consiste en lo siguiente:

  1. Establecer un momento en el día con mínimo o ningún uso de la máquina virtual.
  2. Empleando virsh poner la máquina en pausa.
  3. Efectuar una copia incremental del disco duro utilizando herramientas como bigsync que acabo de empaquetar para Debian y ya está en nuestro repositorio.
  4. Reanudar la actividad de la máquina.

Uno de los principales problemas que vamos a encontrarnos con este esquema es que la máquina va a perder la sincronización horaria paulatinamente. Al final veremos que está demasiado desfasada por lo que tendremos que establecer de alguna manera un mecanismo para arreglarlo que funcione. Por ahora las conexiones con el servidor NTP interno (sigfrido) no están funcionando y no conozco aún la razón.

Otro es encontrar ese momento en el cual la máquina pueda ser detenida sin causar molestias los usuarios ni al resto de las tareas de la red. Calculo que la mejor opción es utilizarlo como una tarea previa a las copias de seguridad aunque aún tengo que ver cómo encaja en el esquema de bacula.

 

Vuelta de vacaciones

2 septiembre 2014

La empresa ha vuelto de vacaciones, y entre lo que he hecho en agosto y estos días de septiembre, hay algunos cambios:

  • He creado un clon de la máquina virtual helena llamado troya, que funciona muy bien y que me permitirá realizar mejores copias de seguridad.
  • He arreglado las estadísticas web de venexma.es para poder analizarlas. También he reducido la frecuencia de construcción de las mismas a una vez al día; cada diez minutos, para el uso que vamos a darle, es excesivo y ralentiza mucho el servidor sigfrido.
  • Varios retoques y mejoras en el paquete de escritorio de la empresa. Incluso he instalado un acceso VNC a los diferentes puestos para poder darles soporte desde fuera.
  • Algunos equipos de usuario se han modificado ligeramente; todo bien excepto el de Alfredo que no marcha y que tendré que sustituir.
  • Una sustitución interesante ha sido la de la máquina zagreb, que utiliza Luismi, y que ahora dispone de un procesador Intel i5 con 8 Gb de RAM y, por el momento, el mismo disco de 500Gb SATA que antes tenía. Es el equipo que yo empleaba en casa por lo que ha venido también con su monitor. Planeo emplearlo como destino de copias para bacula en cuanto pueda añadirle discos extra que están casi preparados.

Por lo demás la web avanza bastante bien, aunque hace un par de días que no sabemos nada de ellos. Será cuestión de insistir.

Actualización

Ya han dado señales de vida y han dicho que están construyendo un manual de uso y arreglando algunos entuertos. En breve volveremos a saber de ellos.

Y respecto a las tareas comunes de primeros de mes: copias de seguridad completas (lo que explica bastante la caída de rendimiento) y estadísticas del mes de julio.

 

Notificación nueva de la AEAT

16 julio 2014

Hoy hemos recibido un aviso de que teníamos una notificación nueva en la web de correos. Como me temía Mariano no ha sido capaz de firmarla debido a problemas con el almacén de certificados de Java, en local, y a que hay una versión nueva del entorno de ejecución de este lenguaje.

El primer problema lo he solventado de la siguiente forma:

  1. Exporto el certificado de la empresa con la contraseña de sesión de Mariano.
  2. Copio el certificado a su máquina.
  3. Instalo el certificado en el almacén de claves local de Java empleando mi programa p12certjava del paquete venexma-sun-java y me aseguro de que tanto el almacén como el certificado comparten la misma clave.

Esto representa un problema de seguridad puesto que su contraseña de sesión no ha cambiado en años y es muy probable que sea conocida por más personal de la empresa pero …

El segundo problema no era tan grave: bastaba con ignorar el aviso de actualizar Java durante el proceso y seguir con él. Como no quiero que eso se repita he actualizado el paquete anteriormente citado a la última versión del Java de Oracle.

 

El servicio de impresión BSD printer

14 julio 2014

Hoy ha habido una actualización importante en Debian. Como resultas de ello se ha desactivado el servicio BSD de impresión en el servidor principal sigfrido y todo lo que procedía de helena -y de la gestión comercial y la contabilidad- quedaba retenido a la espera de que se restableciese la conexión por red.

Tras darle varias vueltas he encontrado que la solución más rápida consiste en reconfigurar el paquete cups-bsd (vía dpkg-reconfigure) y contestar afirmativamente a la única pregunta que realiza: sí, de veras, queremos que se active el servicio.

El punto crucial -y ésto es para los archivos- estaba en el fichero de configuración de inet situado en /etc/inetd.conf.