Soporte #7840
IES Miguel Catalán - Queremos recabar nuestra propia información de inventario de forma local.
#1
Actualizado por Nacho Sancho hace 6 meses
Actualizado por - Se está desplegando también un cliente ocs en los centros (Teruel ya lo tiene) que manda los datos a un servidor central gestionado por aragon.es (ocsce.aragon.es). No se como convivirán éstas dos implementaciones. En Zaragoza va algo mas lento, pero vamos, que tenemos ya preparada la solución para ése despliegue.
- El cliente que instala es la versión 2.9.1. Si me dices que ésta es al versión que hay que instalar, puedo rehusar dicho paquete...no se si tengo que darle algún tag a los equipos (así se hace a nivel central)
- Necesitamos algo de tiempo, pero no será conmplejo
-- nacho
#2
Actualizado por Carlos González Larraga hace 6 meses
Actualizado por - Añadido Fichero 2024-05-17-OCSagente2_9-y10compatibles.jpg 2024-05-17-OCSagente2_9-y10compatibles.jpg
Mil gracias por la labor, Nacho,
y respecto a tus cuestiones,
1.- el caso es que vemos interesante y (por ahora necesario) tener el control local del inventario descomunal de este centro.
Los win en dominio están entrando solos con una orden, claro no entran así los que no están en dominio, (hay que hacerlos a mano uno a uno) en fin.
Aún así entendemos que si algún día llega el despliegue del OCS en la provincia y hay que redirigir los datos a un OCS central, creo que sería fácil.
Bien que nuestro ubuntu server volcase los datos con una frecuencia periódica, en el OCS global, bien redirigir la IP donde se registren los equipos.
Con lo que para entonces (despliegue provincial), ya tendríamos de una u otra forma casi todo el trabajo hecho.
Con el añadido de que ya controlaríamos nuestros datos localmente en el centro.
2.- la versión 2.9.1 del cliente (ocs-ng-agent) funciona bien, te adjunto captura de las 3 versiones de ocs-ng-agent, con las que nuestro OCS en Ubuntu-Server está recogiendo los datos y todos van finos, así que sí se puede reciclar vuestro paquete.
Respecto a la "TAG", cierto se me olvidó ponerla, creo que sería útil "vx-iesmcat" nos servirá ahora para distinguir en local y servirá a futuro para distinguir en provincial o autonómico.
3.- respecto al tiempo sin problemas, en lo que pienso es en tener para el 15 de junio un "Inventario Local" lo más realista posible.
Saludos y gracias por vuestro impagable trabajo, Carlos Glez.
#3
Actualizado por Nacho Sancho hace 6 meses
Hola Carlos, antes de ponerme. Observando lo que hicimos para los Servicios Proviniciales, no creo que en un futuro pudieran convivir "los dos agentes", ya que el mismo hay que instalarlo en tiempo de instalación y se "chocarán". Es decir, se compila cuando se instala y el "iniciador" se despliega cuando se instala. Pero bueno, de momento os lo podemos poner apuntando al vuestro.
Para programarlo acorde a vuestros requisitos, necesito saber si los equipos van a ir "cambiando" de red o cuando se instale el paquete estarán en la red donde tienen que estar y no cambiarán. Es decir, tengo que indicar el server cuando se instala. Se puede hacer que el automáticamente (lo tendría que programar) cuando arranque verifique la red donde está o que dicha "reconfiguración" se pueda hacer manualmente. Lo más cómodo es que no se tenga que verificar automáticamente, pero tu me dices
-- nacho
#4
Actualizado por Nacho Sancho hace 6 meses
Tengo ya una posible prueba que podríamos hacer si quieres...Si eso dame un toque y lo miramos en directo por si acaso
-- nacho
#5
Actualizado por Carlos González Larraga hace 6 meses
Hola Nacho,
en principio NO, no van a ir cambiando de red.
Una vez puesto allí, no debería cambiar, así que, se puede probar.
Y tal vez no haga falta que haya dos agentes en el futuro, si no que los datos recogidos en nuestro unbuntu server se vuelquen directamente en el central, con la frecuencia temporal que sea.
Yo creo que no hace falta que lo verifique automáticamente cada vez, tal vez como indicas dejarlo para una "verificación manual", y fuese una reconfiguración, p. ej. si un equipo se reutiliza y configura en la otra red.
Pero con llamada manual, como cuando se cambia manualmente una etiqueta o se cambia la ip del caché.
Lástima que no he tenido esta mañana tiempo de ver el correo, me habría puesto a probar,...
pero puedo "ponerme cita" para el lunes 20, de 13:15 a 14:05, disponible para ti y estas pruebas.
Ya me dirás.
Muchas gracias, Carlos Glez.
#6
Actualizado por Nacho Sancho hace 6 meses
Venga, cuando tengas el hueco me dices por teléfono si eso
-- nacho
#7
Actualizado por Nacho Sancho hace 6 meses
Cierro la incidencia, pero si da problemas cuando se vaya desplegando la reabres o me dices!
-- nacho
#8
Actualizado por Carlos González Larraga hace 6 meses
Está perfectamente cerrada,
Se están registrando todos según actualizan, sean de una red o de otra, sean con Vx 3.x o con 2.x
Eres como un astralicamano, funciona como un reloj suizo, ... quizás mejor.
Muchas gracias, por vuestro trabajo.
Carlos Glez.
Descripción
Hola Nacho y Arturo,
como os comenté, con la ayuda de OCS inventory, montado en un Ubuntu server, propio del centro, queremos tener un control "local" de nuestro propio inventario.
El caso es que sobre los windows, va bien, hemos recogido datos de 288 máquinas (aún nos faltan unas 115 más...llegarán al registro),
pero sobre los Vitalinux, más de 150 activos, no lo tenemos automatizado, en local. (gracias por el de MigasFree)
Si bien a mano, ya hemos conseguido que se registren 3 (1 de ellos probando con la VPN desde casa), no vemos factible, ni sencilla, nuestra labor.
Pero sé que vosotros sois unos hachas y no os importa el reto, aunque sencillo no es... creo..
Tenemos físicamente dos líneas separadas MCATALAN (admon) y AULAS , así que el mismo OCSinventory nos recoge datos en dos IP's distintas dependiendo, en que línea se conecte el equipo, vamos como tenemos nuestro Caché de Vitalinux (con 10.0.21.1 y con 192.168.21.1, gracias a que tiene dos tarjetas de red)
Pues el Ubuntu Server está igual. tenemos "http://192.168.10.200/ocsinventory" para admon. y "http://10.0.5.200/ocsinventory" que recoge datos de aulas.
Tenemos Vx, en las dos líneas, aunque la gran mayoría está en aulas, no hemos visto como ocs-agent-client, pueda "apuntar" a dos IP, pero....
A la hora de que "marcaráis" con "tag" para OCS, se puede discriminar, según la IP de caché que tienen asignada, es la única forma segura de distinguirlos,
pues puede haber "Etiquetas comunes o intercambiadas en las dos líneas",
Sin embargo, de lo que me aseguro es que si el equipo está en admon, apunta al caché por la IP 192.168.21.1 y si el equipo esta en aulas, apunta al cache en 10.0.21.1.
Pues resumiendo, ... el RETO,
1.- ordenadores con IP caché de 192.168.21.1, que se registren con OCS-inventory en "http://192.168.10.200/ocsinventory"
2.- ordenadores con IP caché de 10.0.21.1, que se registren con OCS-inventory en "http://10.0.5.200/ocsinventory"
Si no fuera posible dicha discriminación, prefiero que se queden con la opción 2 todos, es donde están la mayoria de Vx.
Ánimo y suerte, sé que lo conseguiréis,
y muchas gracias, Carlos Glez.
| 2024-05-17-OCSagente2_9-y10compatibles.jpg (12 KB) 2024-05-17-OCSagente2_9-y10compatibles.jpg | Varios OCS agent válidos, para registro |