Autor Tema: Varios temas con las actualizaciones... (Leído 2198 veces)

Zup · « **en:** 05-01-2022, 08:40 (Miércoles) »

Pues eso, que me fallan varios actualizadores. Algunos los he conseguido arreglar, otros no. Ahí va una lista de problemas y algunas soluciones...

Actualizadores que no detectan (bien) la versión (con soluciones):
- pocl_updater, xxHash_updater y wpscan_updater no detectan bien la versión a bajar, en todos los casos aparece como 'ref' (y no actualiza). La solución para los tres es la misma: ir a la línea 24 del updater (la que empieza por VERSION) y sustituir 'cut -d/ -f5' por 'cut -d/ -f7'
- arp-scan_updater tampoco lee bien la versión (aparece como arp-scan-arp-scan-1.9). La solución es ir a la línea 24 y sustituir '$WEB/releases' por '$WEB/tags'. No hay versión más actual, pero imagino que así funcionará para futuras actualizaciones.

Actualizador que no apunta a donde debe (con solución):
- rtl88x2bu_updater no compila. Descarga un texto donde dice que el repositorio está en otra parte. Para que descargue (y compile), hay que cambiar la línea 20 para que diga 'SRCNAM=88x2bu-20210702'.

¿Qué pasa con los actualizadores de realtek?
Hay un par de actualizadores que SIEMPRE dicen que hay versión nueva (sea cierto o no). Uno de ellos (rtl8188eus) creo que lee mal la versión... tendré que darle una vuelta a ver si lo arreglo.

Paquetes a NO instalar o actualizar:
Probando he descubierto que openssh y polkit no deben ser instalados o actualizados (lo que es una pena porque openssh es el que nos permite usar scp). El problema (en ambos) es que esos paquetes txz tienen scripts de instalación que modifica ficheros en /etc (/etc/passwd, /etc/shadow y /etc/group). Al convertirlos a xzm, estos ficheros no se incluyen y provocan que Wifislax no arranque (se queda pidiendo contraseña y las rechaza todas).

La solución al no arranque es quitar el módulo donde hayamos instalado/actualizado estos paquetes. Actualizarlos ya es más peliagudo... una posible solución sería descomprimir los ficheros txz, poner los ficheros correspondientes y después recomprimir a txz y convertir a xzm... no lo he probado. En cualquier caso, una solución permanente y automatizada conllevaría modificar el script que convierte a xzm o incluir ambos paquetes en la distribución base y crearles updaters específicos.

Otros módulos que NO actualizan:
- wireshark: Varios fallos de compilación, no sé si son debidos a que no se genera bien config.h o a fallos en el repositorio. La última versión que me compiló es la 3.4.5, ahora van por la 3.6.1. Lo más lejos que he llegado ha sido incluyendo <stdint.h> en el fichero ui/qt/rtp_audio_file.h e incluyendo <string.h> en el fichero wsutil/glib-compat.h (y aún así no compila). Se eliminan todos los errores de compilación (solo hay warnings), pero ld protesta porque no encuentra qInitResources_about().
- gslapt y slapt-get. Un caso curioso, protestan (casi) por las mismas cosas. He conseguido compilar slapt-get comentando la línea 64 del Makefile (en esta línea intenta hacer más pequeños los ejecutables, pero los encuentra), pero luego Wifislax falla al intentar conseguir la lista de paquetes (¿fallo al generar el xzm?¿hay que modificar el script?). Curiosamente si slapt-get se compila correctamente, el actualizador de gslapt funciona bien... y gslapt sí es capaz de obtener la lista de paquetes.
- firmwares... por algúin extraño la primera vez que se lanza (manualmente) no recupera la versión, pero la segunda vez sí.

USUARIONUEVO · « **Respuesta #1 en:** 05-01-2022, 22:45 (Miércoles) »

Hola , voy a intentar explicar algunas cosas , para que se e tienda por que a veces , sin saberlo , creamos conflictos de paquete.

Los actualizadores basciamente comparan la version del sistema con la que se detecte en la web del autor , si no son igual se determina que la de la pagina web es mas nueva y por lo tanto veremos el mensaje de evrsion nueva.

Normalmente un paquete trabaja con numeros enteros de esta forma

paquete-1.1
paquete-1.2

de manera que el script aunque tengas varias versiones , siempre compara el numero mas alto del sistema , con la de la pagina web.

con los drivers , eso no funciona , por que no usan numeros enteros ...usan el commit identificador de movimiento mas reciente en el codigo , y pueden ser cosas asi

12dcg4
rft6548

por lo que ordenar alfabeticamente o numericamente no sirve de nada

cuando guardais algo en modules en un xzm , lo que haceis es que teneis la version vieja + la nueva , cuando lo ideal seria tener solo siempre la mas nueva. si son paquetes que se identifican en version con numeros enteros , no hay problema aunque haya varios , con los drivers si , por que no se reflejan igual.

Juraria que para el modo live , las actualizaciones estan desactivadas por que maneterlo para live es mas complicado que en hdd ya que en live tendrias que saber donde esta cada cosa , para simplemente actualizarla en lugar de ir sumando versiones en modules.

Por eso los drivers realtek , te van a decir siempre que hay versiones nuevas , sea verdad o no , por que tienes mas de una en modo live.

-----------------------------
tema wireshark , no compilan las versiones nuevas , no se por que , ni tampoco lo voy a mirar , este mes saldra version nueva de wifislax con todo actualizado , no voy a perder tiempo en un problema de una version anterior.

---------------------------
temas actualizadores que no ven correctamente la version y necesitan ajustes ... los puedo arreglar.

USUARIONUEVO · « **Respuesta #2 en:** 05-01-2022, 22:47 (Miércoles) »

me acabo de dar cuenta que hablas de actualizadores que no estan ni en wifislax 2.4 ...

¿que version estas usando?

no doy soporte a versiones viejas, asi que hasta aqui he llegado.

Zup · « **Respuesta #3 en:** 06-01-2022, 11:13 (Jueves) »

Utilizo una Wifislax 2.4 en pendrive USB, el kernel es 5.4.91. El fichero changelog tiene entradas hasta el 20/01/2021.

Al margen de eso, tiene instalados los siguientes módulos en \wifislax64\modules:
- Driver_nvidia-460.32.03-x86_64-1wifislax.xzm
- cudatoolkit-10.2.89-x86_64-1slackbuilds.xzm
- Multilib-kit-14.2-2wifislax.xzm
- multimedia-common-1.0-8wifislax.xzm
- webkit2gtk-kit-2.20.5-1wifislax.xzm

Los actualizadores han sido actualizados mediante el menú, la versión instalada es del 20220106.

Los dos únicos paquetes que menciono que no tienen updaters propios (se instalan a través de gslapt) son openssh y polkit. Por lo que he visto, slapt-get y gslapt tienen actualizadores propios pero también pueden instalarse a través de gslapt (no están bloqueados como el resto de librerías).

(Otra posible "solución" al problema de openssh y polkit sería incluir ambos en la distribución base y marcarlos como "bloqueados" en slapt-get/gslapt para que no actualicen nunca)

Añado un listado de los updaters que están presentes cuando arranco:

Código: [Seleccionar]

Auditoria:
  aircrack-ng_updater
  arp-scan_updater
  bully_updater
  ettercap_updater
  hashcat-utils_updater
  hashcat_updater
  hydra_updater
  ipscan_updater
  johnny_updater
  nmap_updater
  patrones-conocidos_updater
  pixiewps_updater
  wireshark_updater

Drivers:
  rtl8188eus_updater
  rtl8192eu_updater
  rtl8814au_updater
  rtl88XXau_updater
  rtl88x2bu_updater

Funciones:
  funciones_updater

Internet:
  frostwire_updater
  teamviewer_updater
  xampp_updater

Juegos:
  four-in-a-row_updater
  kde-games_updater

Librerias:
  ffmpeg_updater
  libnfc_updater
  libquicktime_updater
  pocl_updater
  transcode_updater
  xxHash_updater

Multimedia:
  HandBrake_updater
  ardour_updater
  audacity_updater
  avidemux_updater
  bluray-keys_updater
  exaile_updater
  kodi_updater
  lives_updater
  vlc_updater

Navegadores:
  firefox_updater
  google-chrome_updater

Oficina:
  libreoffice-helppack_updater
  libreoffice-langpack_updater
  libreoffice_updater
  openoffice_updater

Pentest:
  WebSploit-Framework_updater
  armitage_updater
  bulk_extractor_updater
  burpsuite_updater
  facebook_hack_tool_updater
  metasploit_updater
  pentbox_updater
  web-sorrow_updater
  wpscan_updater

Sistema:
  firmwares_updater
  gslapt_updater
  jdk_updater
  linux_updater
  slapt-get_updater
  wifislax-updaters_updater

EDITO: Arrancando la ISO en una máquina virtual fallan los mismos updaters y de la misma manera. El fichero que uso es wifislax64-2.4-final.iso con md5 15a709c588e85de6157645e8d64fa2ed

USUARIONUEVO · « **Respuesta #4 en:** 06-01-2022, 18:47 (Jueves) »

(Otra posible "solución" al problema de openssh y polkit sería incluir ambos en la distribución base y marcarlos como "bloqueados" en slapt-get/gslapt para que no actualicen nunca)

claro claro

Mientras lo hagas solo para ti ,adelante

Zup · « **Respuesta #5 en:** 24-01-2022, 10:58 (Lunes) »

Volviendo al tema de los drivers (y posiblemente otros actualizadores basados en git)...

Por algún extraño motivo, la detección de versiones en los Drivers me sigue fallando como una escopeta de feria. Alguno de los drivers no se ha actualizado en meses y me cambia de versión cada día.

Mi sugerencia (por ahora creo que me funciona) sería ir a la página de commits y coger el número más reciente. En el caso del actualizador rtl8188eus, sólo habría que cambiar una línea y quedaría como esta:

Código: [Seleccionar]

VERSION="5.3.9_$(curl -s $WEB/commits/v5.3.9|grep commit/|head -1|cut -d / -f7|cut -c 1-7)"
Otra sugerencia, mejorando un poco la usabilidad sería cambiar el número de versión por la fecha del último commit. En estos actualizadores, creo que la versión es algo informativo y que siempre se descarga la última versión mediante git clone, por lo que cambiar un número de commit por su fecha no debería afectar al resto del script. En el mismo actualizador, esto se conseguiría con esta líneas:

Código: [Seleccionar]

Código: [Seleccionar]

	FECHA=$(curl -s $WEB/commits/v5.3.9|grep "Commits on"|head -1|cut -d'>' -f2 | cut -d '<' -f1| cut -d' ' -f3-5)
	ANO=$(echo $FECHA | cut -c 9-12)
	MES=$(echo $FECHA | cut -c 1-3)
	DIA=$(echo $FECHA | cut -c 5-6)
	VERSION="5.3.9_${ANO}${MES}${DIA}"

...aunque esto último solo sería útil si se convirtiera el MES en un número y se hiciera una actualización totalmente automatizada (sin consultar al usuario).

USUARIONUEVO · « **Respuesta #6 en:** 24-01-2022, 14:21 (Lunes) »

Cita de: Zup en 24-01-2022, 10:58 (Lunes)

Volviendo al tema de los drivers (y posiblemente otros actualizadores basados en git)...

Por algún extraño motivo, la detección de versiones en los Drivers me sigue fallando como una escopeta de feria. Alguno de los drivers no se ha actualizado en meses y me cambia de versión cada día.

Mi sugerencia (por ahora creo que me funciona) sería ir a la página de commits y coger el número más reciente. En el caso del actualizador rtl8188eus, sólo habría que cambiar una línea y quedaría como esta:
Código: [Seleccionar]
VERSION="5.3.9_$(curl -s $WEB/commits/v5.3.9|grep commit/|head -1|cut -d / -f7|cut -c 1-7)"
Otra sugerencia, mejorando un poco la usabilidad sería cambiar el número de versión por la fecha del último commit. En estos actualizadores, creo que la versión es algo informativo y que siempre se descarga la última versión mediante git clone, por lo que cambiar un número de commit por su fecha no debería afectar al resto del script. En el mismo actualizador, esto se conseguiría con esta líneas:
Código: [Seleccionar]
VERSION=$(curl -s $WEB/commits/v5.3.9|grep "Commits on"|head -1|cut -d'>' -f2 | cut -d '<' -f1| cut -d' ' -f3-5)
Yendo un poco más lejos, se puede reordenar la fecha para que se pueda ver más rápido si la versión es más reciente...
Código: [Seleccionar]
FECHA=$(curl -s $WEB/commits/v5.3.9|grep "Commits on"|head -1|cut -d'>' -f2 | cut -d '<' -f1| cut -d' ' -f3-5) ANO=$(echo $FECHA | cut -c 9-12) MES=$(echo $FECHA | cut -c 1-3) DIA=$(echo $FECHA | cut -c 5-6) VERSION="5.3.9_${ANO}${MES}${DIA}"
...aunque esto último solo sería útil si se convirtiera el MES en un número y se hiciera una actualización totalmente automatizada (sin consultar al usuario).

Lo de usar la fecha en lugar del identificador de commit, es lo unico en lo que pense hace un tiempo y lo unico que valdria la pena

quedando las versiones algo asi

5.3.8_220220124 por ejemplo.

De todas formas tu problema lo sigues generando tu solito , por que en lugar de coger el modulo wifislax-drivers y actualizarlos, lo que haces es ir hechando modulos a la carpeta modules sin quitar las versiones viejas dentro de los modulos que lo contengan , ese es tu problema real y ningun otro , mas aun cuando vienen desactivados en el modo live , y que se activan al instalar en hdd , en donde el instalador realmente puede eliminar la version vieja cuando instala la nueva dejando solo la ultima en lugar de acumular versiones.

Estudiare lo de la fecha , por que es lo unico que vale la pena mirar

USUARIONUEVO · « **Respuesta #7 en:** 24-01-2022, 14:23 (Lunes) »

Ten en cuenta que los "actualizadores" ,pueden actualizar en un sistema instalado , pero en un live , el script bajara y hara el modulo ...pero tu debes ser quien finalmente hagas esa actualizacion permanente , mediante la eliminacion/actualizacion.

Lo que decias de los problemas de polkit ............idem , tu solito te creas los problemas , por que en lugar de coger el modulo de slackware que tiene la version vieja , y actualizarla , lo ue haces es meter una mas en modules ...

Noticias:

Autor Tema: Varios temas con las actualizaciones... (Leído 2198 veces)

Zup

Varios temas con las actualizaciones...

USUARIONUEVO

Re:Varios temas con las actualizaciones...

USUARIONUEVO

Re:Varios temas con las actualizaciones...

Zup

Re:Varios temas con las actualizaciones...

USUARIONUEVO

Re:Varios temas con las actualizaciones...

Zup

Re:Varios temas con las actualizaciones...

USUARIONUEVO

Re:Varios temas con las actualizaciones...

USUARIONUEVO

Re:Varios temas con las actualizaciones...