Re: Alternativa a kill -9
El martes, 27 de octubre de 2015 a las 16:56 UTC Maykel Franco escribió: > El día 27 de octubre de 2015, 17:50, Manolo Díaz > escribió: > > El martes, 27 de octubre de 2015 a las 16:42 UTC > > Maykel Franco escribió: > > > >> El día 27 de octubre de 2015, 17:35, Manolo Díaz > >> escribió: > >> > El martes, 27 de octubre de 2015 a las 16:28 UTC > >> > Maykel Franco escribió: > >> > > >> >> > ¿Puedes ver qué proceso lo ocupa aparte de 757250? > >> >> > > >> >> > -- > >> >> > Manolo Díaz > >> >> > > >> >> > >> >> Esto por un lado: > >> >> > >> >> root@test:/var/lib/vz# ps aux | grep -i lzop > >> > > >> > [...] > >> > > >> >> root@test:/var/lib/vz# lsof -p 757250 > >> > > >> > No, me refería a quién ocupa /proc/757250/fd/0 > >> > > >> > lsof | grep /proc/757250/fd/0 > >> > > >> > > >> > -- > >> > Manolo Díaz > >> > > >> > >> > >> Me devuelve bastantes lineas que se repiten estas dos: > >> > >> lsof: no pwd entry for UID 110 > >> lsof: no pwd entry for UID 111 > >> > > > > Usuarios de sistema. Mira a ver si tienen procesos abiertos anteriores > > al 15 de octubre. > > > > -- > > Manolo Díaz > > > > Quieres que obtenga los procesos de ese identificador uid > correspondiente a los usuarios de sistema? > Sí, ps x u110 ps x u111 -- Manolo Díaz
Re: Alternativa a kill -9
El martes, 27 de octubre de 2015 a las 16:28 UTC Maykel Franco escribió: > > ¿Puedes ver qué proceso lo ocupa aparte de 757250? > > > > -- > > Manolo Díaz > > > > Esto por un lado: > > root@test:/var/lib/vz# ps aux | grep -i lzop [...] > root@test:/var/lib/vz# lsof -p 757250 No, me refería a quién ocupa /proc/757250/fd/0 lsof | grep /proc/757250/fd/0 -- Manolo Díaz
Re: Alternativa a kill -9
El martes, 27 de octubre de 2015 a las 16:42 UTC Maykel Franco escribió: > El día 27 de octubre de 2015, 17:35, Manolo Díaz > escribió: > > El martes, 27 de octubre de 2015 a las 16:28 UTC > > Maykel Franco escribió: > > > >> > ¿Puedes ver qué proceso lo ocupa aparte de 757250? > >> > > >> > -- > >> > Manolo Díaz > >> > > >> > >> Esto por un lado: > >> > >> root@test:/var/lib/vz# ps aux | grep -i lzop > > > > [...] > > > >> root@test:/var/lib/vz# lsof -p 757250 > > > > No, me refería a quién ocupa /proc/757250/fd/0 > > > > lsof | grep /proc/757250/fd/0 > > > > > > -- > > Manolo Díaz > > > > > Me devuelve bastantes lineas que se repiten estas dos: > > lsof: no pwd entry for UID 110 > lsof: no pwd entry for UID 111 > Usuarios de sistema. Mira a ver si tienen procesos abiertos anteriores al 15 de octubre. -- Manolo Díaz
Re: Alternativa a kill -9
El martes, 27 de octubre de 2015 a las 16:13 UTC Maykel Franco escribió: > El día 27 de octubre de 2015, 17:09, Manolo Díaz > escribió: > > El martes, 27 de octubre de 2015 a las 15:40 UTC > > Maykel Franco escribió: > > > >> El día 27 de octubre de 2015, 16:36, Carlos Zuniga > >> escribió: > >> > On Mon, Oct 26, 2015 at 5:10 PM, Maykel Franco > >> > wrote: > >> >> El día 26 de octubre de 2015, 22:26, Manolo Díaz > >> >> escribió: > >> >>> El lunes, 26 de octubre de 2015 a las 21:24 UTC > >> >>> abaddon sinnerman escribió: > >> >>> > >> >>>> Lo dice muy clao;reiniciar el servidor o esperar : You can only clear > >> >>>> them by rebooting the server or waiting for the I/O to respond. > >> >>> > >> >>> Uno de los procesos lleva esperando desde el 15 de junio, el otro > >> >>> solamente desde el 15 de octubre. > >> >>> > >> >>> -- > >> >>> Manolo Díaz > >> >>> > >> >> > >> >> Si, eso lo sé Manolo, pero es que soy incapaz de matarlo... Me estoy > >> >> desesperando jejeje > >> >> > >> > > >> > Y a que I/O esta esperando? > >> > > >> > Y me parece rara esta línea de tu lsof > >> > > >> >> ... (deleted)/usr/bin/lzop > >> > > >> > Has borrado el binario? > >> > > >> > >> No: > >> > >> root@test:/var/lib/vz# which lzop > >> /usr/bin/lzop > >> root@test:/var/lib/vz# ls -l /usr/bin/lzop > >> -rwxr-xr-x 1 root root 65296 nov 8 2011 /usr/bin/lzop > >> > > > > Lo que parece perdido es la entrada estándar de ese proceso, en la que > > espera 65296 bytes > > > > Como prueba desesperada: > > echo > /proc/674388/fd/0 > > > > (asegúrate de que no he confundido el número de proceso) sabiendo que, > > en caso de funcionar, perderías esos 65296. > > -- > > Manolo Díaz > > > > Se lo he pasado pero no hace nada... > > Eso sí, en el proceso de lzop de Junio, si me dice algo al ejecutar ese > comando: > > root@test:/mnt# echo > /proc/757250/fd/0 > bash: /proc/757250/fd/0: El fichero de texto está ocupado > ¿Puedes ver qué proceso lo ocupa aparte de 757250? -- Manolo Díaz
Re: Alternativa a kill -9
El martes, 27 de octubre de 2015 a las 15:40 UTC Maykel Franco escribió: > El día 27 de octubre de 2015, 16:36, Carlos Zuniga > escribió: > > On Mon, Oct 26, 2015 at 5:10 PM, Maykel Franco > > wrote: > >> El día 26 de octubre de 2015, 22:26, Manolo Díaz > >> escribió: > >>> El lunes, 26 de octubre de 2015 a las 21:24 UTC > >>> abaddon sinnerman escribió: > >>> > >>>> Lo dice muy clao;reiniciar el servidor o esperar : You can only clear > >>>> them by rebooting the server or waiting for the I/O to respond. > >>> > >>> Uno de los procesos lleva esperando desde el 15 de junio, el otro > >>> solamente desde el 15 de octubre. > >>> > >>> -- > >>> Manolo Díaz > >>> > >> > >> Si, eso lo sé Manolo, pero es que soy incapaz de matarlo... Me estoy > >> desesperando jejeje > >> > > > > Y a que I/O esta esperando? > > > > Y me parece rara esta línea de tu lsof > > > >> ... (deleted)/usr/bin/lzop > > > > Has borrado el binario? > > > > No: > > root@test:/var/lib/vz# which lzop > /usr/bin/lzop > root@test:/var/lib/vz# ls -l /usr/bin/lzop > -rwxr-xr-x 1 root root 65296 nov 8 2011 /usr/bin/lzop > Lo que parece perdido es la entrada estándar de ese proceso, en la que espera 65296 bytes Como prueba desesperada: echo > /proc/674388/fd/0 (asegúrate de que no he confundido el número de proceso) sabiendo que, en caso de funcionar, perderías esos 65296. -- Manolo Díaz
Re: Alternativa a kill -9
El lunes, 26 de octubre de 2015 a las 21:24 UTC abaddon sinnerman escribió: > Lo dice muy clao;reiniciar el servidor o esperar : You can only clear > them by rebooting the server or waiting for the I/O to respond. Uno de los procesos lleva esperando desde el 15 de junio, el otro solamente desde el 15 de octubre. -- Manolo Díaz
Re: Alternativa a kill -9
El lunes, 26 de octubre de 2015 a las 21:05 UTC Maykel Franco escribió: > El día 26 de octubre de 2015, 22:02, Manolo Díaz > escribió: > > El lunes, 26 de octubre de 2015 a las 20:36 UTC > > Maykel Franco escribió: > > > >> Nada no consigo quitarlos... > >> > >> No aparecen tampoco como zombies... > >> Alguna idea? > > > > root 674388 0.0 0.0 6828 1228 ?Doct15 0:00 lzop > > > > ¿con qué orden y parámetros has obtenido esa línea? > > ps aux | grep lzop Entonces esa D no es de defunct, sino de uninterruptible sleep. ¿Has usado esa orden con sistema de ficheros remoto? -- Manolo Díaz
Re: Alternativa a kill -9
El lunes, 26 de octubre de 2015 a las 20:36 UTC Maykel Franco escribió: > Nada no consigo quitarlos... > > No aparecen tampoco como zombies... > Alguna idea? root 674388 0.0 0.0 6828 1228 ?Doct15 0:00 lzop ¿con qué orden y parámetros has obtenido esa línea? -- Manolo Díaz
Re: Alternativa a kill -9
El lunes, 26 de octubre de 2015 a las 18:45 UTC Roberto Quiñones escribió: > El 26-10-2015 15:30, "Manolo Díaz" escribió: > > > > El lunes, 26 de octubre de 2015 a las 18:21 UTC > > Pablo Mercader Alcántara escribió: > > > > > > > Buenas, existe alguna alternativa a este comando? Poder usar otro y > > > > > que a lo mejor tenga más efectividad... > > > > > > > > No. > > > > > > ¿Y que hay de "kill -s 15 pid"? > > > > La señal 15 puede ser ignorada o pospuesta por el proceso. De esta > > manera se puede cerrar ordenadamente una aplicación, por ejemplo. La 9 > > no. > > Puedes intentar con pkill + nameprocess :) Sí, pero las señales que le puede enviar al proceso son las mismas. -- Manolo Díaz
Re: Alternativa a kill -9
El lunes, 26 de octubre de 2015 a las 18:21 UTC Pablo Mercader Alcántara escribió: > > > Buenas, existe alguna alternativa a este comando? Poder usar otro y > > > que a lo mejor tenga más efectividad... > > > > No. > > ¿Y que hay de "kill -s 15 pid"? La señal 15 puede ser ignorada o pospuesta por el proceso. De esta manera se puede cerrar ordenadamente una aplicación, por ejemplo. La 9 no. -- Manolo Díaz
Re: Alternativa a kill -9
El lunes, 26 de octubre de 2015 a las 17:14 UTC Maykel Franco escribió: > Buenas, existe alguna alternativa a este comando? Poder usar otro y > que a lo mejor tenga más efectividad... No. > Tengo estos 2 procesos que soy incapaz de sacarlos de la memoria: > > root 674388 0.0 0.0 6828 1228 ?Doct15 0:00 lzop > root 757250 0.0 0.0 6828 380 ?Djun15 0:00 lzop > > Y la máquina, por ciertos motivos, no puedo apagarla. > > Gracias de antemano. https://en.wikipedia.org/wiki/Zombie_process -- Manolo Díaz
Re: Jessie backport kernel
El domingo, 25 de octubre de 2015 a las 09:21 UTC Josu Lazkano escribió: > Hola a todos, > > Tengo un servidor en Jessie pero necesito tener el kernel 4.2 por > disponer de drivers para un hardware reciente. > > He visto que acaba de salir la 4.2 en los backports de Jessie. Mi duda > es: si instalo de esta manera "apt-get install > linux-image-4.2.0-0.bpo.1-amd64", ¿cuando saquen la version 4.3 se me > actualizara? ¿O me quedare en la rama 4.2? Te quedarás en la 4.2 > No es que me procupe, pero me gustaria que se fuere actualizando > automaticamente. Pues entonces busca linux-image* sin número de versión en backports. > Un saludo y gracias por todo. -- Manolo Díaz
Re: deblan de 7.9 a 8.2
El jueves, 22 de octubre de 2015 a las 17:58 UTC Fabián Bonetti escribió: > Repase muchas respuestas... > > lo que noto es que > > /var/log/daemon.log 267mb > > /var/log/messages 466mb > > /var/log/syslog 3gb > > /var/log/syslog.1 944mb > > /var/log/user.log 9.2gb > > a penas arrancado el debian ya come come un V8 > > > :s ¿Rotan esos ficheros regularmente, funciona correctamente logrotate? -- Manolo Díaz
Re: [OT] Reemplazar enlaces por originales conservando el nombre del enlace
El miércoles, 21 de octubre de 2015 a las 22:00 UTC+2 Manolo Díaz escribió: > for i in * > do > ORIG=$(readlink -m $i) > BASENAME=$(basename $ORIG) > cp $ORIG $DIR_ENLACES/$i > done La segunda línea del bucle es completamente inútil. -- Manolo Díaz
Re: [OT] Reemplazar enlaces por originales conservando el nombre del enlace
El miércoles, 21 de octubre de 2015 a las 19:29 UTC listascor...@msjs.co escribió: > Leyendo de nuevo, es posible que haya cometido una breve equivocación y > de ser así pido disculpas. > Este tema genera una pequeña confusión mental que hay que saber > detectarla para poder entender el asunto... y trataré de desenredarla. > > Los invito a que hagamos el siguiente ejercicio mental: > > Tengo 2 ficheros: > > nombre del fichero 1 (enlace): azul-claro > contenido del fichero 1: imagen azul clara > > nombre del fichero 2: azul-celeste > contenido del fichero 2: imagen azul clara > > > El fichero azul-claro es un enlace al fichero azul-celeste > > Quiero ¿desenlazar? el fichero azul-claro por el fichero azul-celeste > manteniendo el nombre del fichero azul-claro > > Resultado: > > nombre del fichero 1: azul-claro > contenido del fichero 1: imagen azul clara > > nombre del fichero 2: azul-celeste > contenido del fichero 2: imagen azul clara > > > Nota: en el archivo ”fc1” es una lista, estructurada así: > enlace - destino-del-enlace > enlace - destino-del-enlace > enlace - destino-del-enlace > ... Al igual que Fernando, yo me olvidaría de ese fichero con el listado. Sea DIR_ENLACES la variable que contiene la ruta hasta el directorio con los enlaces simbólicos. # hacemos una copia de seguridad del directorio mv $DIR_ENLACES $DIR_ENLACES.bak mkdir $DIR_ENLACES # Este bucle supone que las rutas no contiene espacios. cd $DIR_ENLACES.bak for i in * do ORIG=$(readlink -m $i) BASENAME=$(basename $ORIG) cp $ORIG $DIR_ENLACES/$i done Al acabar debes tener: - El directorio de copias de seguridad con los enlaces - El antiguo directorio con los ficheros enlazados intactos - El que fuera el directorio de enlaces ahora contiene lo que quieres. Nota: no lo he probado. Antes de ejecutar cambia la tercera línea del cuerpo del bucle por echo cp $ORIG $DIR_ENLACES/$i a modo de prueba en dique seco. Suerte. -- Manolo Díaz
Re: Problema con el logical sector size
El miércoles, 21 de octubre de 2015 a las 17:21 UTC
José Miguel (sio2) escribió:
> En cualquier caso, ya me han conectado el disco por SATA:
>
> #v+
> # blockdev --report /dev/sd{a,b}
> RORA SSZ BSZ StartSecSize Device
> rw 256 512 4096 0 1000204886016 /dev/sda
> rw 256 512 512 0 1000203804160 /dev/sdb
> #v-
>
> Este sdb es el antiguo sdc. Ahora ambos tamaños lógicos son de 512.
¿Y ha pasado de
SSZ BSZ
4096 4096
a
512 512
? Me resulta muy extraño.
--
Manolo Díaz
Re: /etc/mtab is not a symlink or not pointing to /proc/self/mounts
El miércoles, 21 de octubre de 2015 a las 13:10 UTC José Maldonado escribió: > El día 20 de octubre de 2015, 19:42, Héctor Palacios > escribió: > > > > Buena Noche > > > > > > Hoy he querido instalar debian testing en otra partición para hacer pruebas. > > Todo ha resultado bien hasta que al reiniciar después de la instalación el > > sistema se ha congelado y muestra el mensaje que ilustra el tema del correo. > > > > > > Parece ser un bug según he visto haciendo una búsqueda-internet. > > Según veo no soy el único a quien le ha pasado: > > > > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1364055.html > > > > Ver al promediar la página: > > > > https://github.com/systemd/systemd/issues/1495#issuecomment-148744470 > > una imagen del mensaje. > > > > Parece tener solución (aún no la he probado). > > > > Antes de intentar los pasos ilustrados en una de las dos páginas > > mencionados, > > hay algún comentario al respecto de este bug? > > Parece ser muy reciente. > > > > Un saludo, > > > > > > > > > Ese es un bug muy viejo y conocido, tanto a si que durante la > transición de ArchLinux lo tuvieron en cuenta, algo que se les paso > por alto a los devs de Debian. > > El bug tiene fácil arreglo, solo has un enlace entre /proc/self/mounts > a /etc/mtab, eso lo puedes hacer con ln -s /proc/self/mounts /etc/mtab No sé. Tanto /etc/init.d/checkroot.sh (inicio sysv) como /lib/systemd/system/debian-fixup.service (systemd) parecen asegurarse de que apunten a /proc/mounts. Hablo de Debian testing. > El bug también tiene su reporte ya realizado, por lo que me parece > raro que no lo hayan solucionado en las point releases. > > Saludos. -- Manolo Díaz
Re: Problema con el logical sector size
El martes, 20 de octubre de 2015 a las 17:14 UTC José Miguel (sio2) escribió: > Un saludo a la lista: > > Se me ha planteado el siguiente problema. Tengo un servidor con un disco > que tiene preparado un RAID 1 (por software) y viendo que parece ir > bien, le voy a añadir un segundo disco para que realmente el RAID haga > su labor. Mi intención era copiar la tabla de particiones del primer > disco en el segundo y añadirlo al RAID. Pero me ha surgido un imprevisto > al intentar hacer lo primero. Al final el problema está en esto: > > # blockdev --report /dev/sda /dev/sdc > RORA SSZ BSZ StartSecSize Device > rw 256 512 4096 0 1000204886016 /dev/sda > rw 256 4096 4096 0 1000204886016 /dev/sdc > > sda es el disco sobre el que está instalado el sistema (disco SATA) y > sdc es este segundo disco (ahora mismo conectado por USB). "sdb" es un > disco es un tercer disco que no pinta nada en el asunto, conectado por > USB. > > El problema lo tengo en la columa SSZ (la que representa el tamaño > lógico de los sectores): no es el mismo y cuando intento hacer la copia > de la tabla de particiones falla. Además de que no sé si para que > funcionaran en RAID debería ser igual el valor. > > No sé si está relacionado con el hecho de que sdc esté conectado por USB > y no por SATA. Como no tengo acceso físico al servidor, pedí que me > conectaran el disco de esta forma a fin de borrarle todo el contenido y > preparar las particiones, porque este disco contenía un sistema > arrancable y no quería correr el riesgo de que si me lo enchufaban > directamente por SATA arrancara este sistema y no el sistema actual. > Obviamente hecha esta primera fase, ordenaría que lo enchufaran dentro > para completar el RAID. > > ¿Alguien sabe algo? Creo que voy a decirles que lo enchufen por SATA (a > fin de cuentas he borrado las particiones, así que ya no arrancará), > pero no sé si alguien sabrá conocerá algo al respecto. > > Gracias de antemano. Precisamente hace unos días me pasó algo similar. Se trataba de un disco externo SATA para copias de seguridad que conecto y desconecto en caliente. Como parte del proceso se verifica la partición antes de montarla, y fsck retornó con un error de tamaño de sector 0. Aún así pude montar la partición y desmontarla. Tras ello el error desapareció. Ni idea de por qué ocurrió. El núcleo usado era Linux 4.2.1. Dudo que sea por el tipo de conexión (SATA/USB): ese es un parámetro del disco duro, o tal vez del firmware que usa. -- Manolo Díaz
Re: ¿Qué sucede con los paquetes huérfanos?
El lunes, 19 de octubre de 2015 a las 13:52 UTC Camaleón escribió: > Los paquetes huérfanos quedan huérfanos si nadie se encarga de ellos y > desaparecen de los repositorios si no se mantienen. Más que huérfano importa si tienen un número aceptable de usuarios. https://wiki.debian.org/qa.debian.org/removals -- Manolo Díaz
Re: ¿Qué sucede con los paquetes huérfanos?
El lunes, 19 de octubre de 2015 a las 01:25 UTC Miguel de Dios Matias escribió: > Pero me surge una duda...bueno dos. > > ¿Qué sucede con los paquetes huérfanos? ¿Se sacan de la siguiente release? No necesariamente. Lo que hace que un paquete no embarque en la próxima versión estable son fallos abiertos con severidad RC. Aquí tienes una larga lista de ejemplos (no todos, el filtro que he usado es muy burdo, pero sí la mayoría, aquello cuyo asunto comienzan por "O: ") de paquetes huérfanos incluidos en Jessie: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=wnpp;include=subject%3AO%3A;dist=stable -- Manolo Díaz
Re: deblan de 7.9 a 8.2
El domingo, 18 de octubre de 2015 a las 16:39 UTC Eduardo Rios escribió: > El 18/10/15 a las 18:25, Manolo Díaz escribió: > > El domingo, 18 de octubre de 2015 a las 15:50 UTC > > Eduardo Rios escribió: > > > >> Yo creo que hubiera sido mejor que hubieras ido actualizando en su > >> momento: de 7.9, a 8.0, 8.1 y 8.2. > > > > El repositorio de estable apunta a la versión 8.2 en este momento, > > tendías que buscar entre las imágenes iso del archivo. Además, debe ser > > un poco más fiable actualizar de 7.9 a 8.2 que a 8.0, por tener la > > primera más errores corregidos. > > > > ¿Quieres decir que "en teoría" se podría pasar de 7.9 a 8.2 sin tanto > problema? Los mismos que pueda tener pasar de 7.9 a 8.0. > Yo es que siempre he ido actualizando de versión a versión, > sin dejar saltos, (7, 7.1, 7.2 ... 8, 8.1, 8.2) y no he tenido problemas. > > Por eso desconozco si se puede actualizar con saltos grandes o muy > grandes (por ejemplo de 7.1 a 8.2) > > A mi no me gusta hacerlo así :-P > Sí, mejor, pero porque tienes las últimas correcciones a fallos en cada momento, no porque deba haber más problemas en pasar de 7.0 a 8.2. El número menor de versión no debe incorporar cambios drásticos. -- Manolo Díaz
Re: deblan de 7.9 a 8.2
El domingo, 18 de octubre de 2015 a las 15:50 UTC Eduardo Rios escribió: > Yo creo que hubiera sido mejor que hubieras ido actualizando en su > momento: de 7.9, a 8.0, 8.1 y 8.2. El repositorio de estable apunta a la versión 8.2 en este momento, tendías que buscar entre las imágenes iso del archivo. Además, debe ser un poco más fiable actualizar de 7.9 a 8.2 que a 8.0, por tener la primera más errores corregidos. -- Manolo Díaz
Re: deblan de 7.9 a 8.2
El domingo, 18 de octubre de 2015 a las 04:38 UTC Fabián Bonetti escribió: > Bueno hacer el dlstupgrade del deblan 7.9 a 8.2 me recordo a las > vers1ones de ubuntu. > > Tuve muchos problemas. > > Xorg > > gdm3 > > y ahora se me llena el dlsco duro... no solo a mi he visto a otro en > interet quejandoce que se llena el discoduro de cosas > en /var/log/message etc y anda saber por donde mas se llena Vamos, que ni siquiera le han echado un vistazo para ver qué lo llena, ¿no? > Es mi oplnion personal... pero recomlendo no hacer el salto. > > Es mas hasta vl una pantalla al remover systemd que para removerlo > debla poner una frase absurda o no se removla. Usa esa estrategia para asegurarse de que no procedes sin haber comprendido el peligro potencial que conlleva, que no respondes automáticamente sin leer ni pensar. -- Manolo Díaz
Re: problemas con nouveau en testing
El viernes, 16 de octubre de 2015, a las 00:25 UTC
Gonzalo Rivero escribió:
> salió al privado por error :-/ estúpidos webmail
>
> El día 15 de octubre de 2015, 10:49, Camaleón escribió:
> > El Wed, 14 Oct 2015 21:40:32 -0300, Gonzalo Rivero escribió:
> >
> >> Holas el lunes actualicé mi testing y seguí trabajando, luego apagué y
> >> por causas que no vienen al caso recién ahora vuelvo a encender esta
> >> computadora.
> >> Lo primero que me llamó la atención es que no se ve por las dos
> >> pantallas, tengo una conectada por vga (no anda ahora) y otra por hdmi
> >> ("anda" a la fabulosa resolución de 1024x768), misma placa de video.
> >
> > (...)
> >
> >> Ahora, hace mas de un año, venía usando los drivers nouveau sin ningún
> >> problema; el xrandr me muestra esto:
> >> sfish@gonzalo:~$ xrandr xrandr: Failed to get size of gamma for output
> >> default Screen 0: minimum 640 x 480, current 1024 x 768, maximum 1024 x
> >> 768 default connected primary 1024x768+0+0 0mm x 0mm
> >>1024x768 61.00*
> >>800x600 61.00 640x480 60.00
> >
> > No detecta la salida VGA.
> >
[...]
> > Espera... el módulo se llama "nouveau" no "nv", ese es otro, anterior y
> > sin soporte para aceleración 3D. Puedes probar a forzar su carga creando
> > un archivo de configuración mínimo en "/etc/X11/xorg.conf" con este
> > contenido:
> >
> > Section "Device"
> > Identifier "nouveau"
> > Driver "nouveau"
> > EndSection
> >
> >> ¿por donde podría empezar a buscar?
> >
> > Pues por ver si te dice la verdad:
> >
> > locate nv.ko
> > locate nouveau.ko
> >
> > Saludos,
> >
> > --
> > Camaleón
> >
> tengo nouveau.ko (en
> /lib/modules/4.2.0-1-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko),
> no tengo nv.
Creo que ese último es para el controlador propietario.
> Me tocará revisar porque no lo carga, o que no le gusta
Sí lo carga, como puedes ver en tu correo original, pero prefiere el
VESA.
--
Manolo Díaz
Re: problemas con nouveau en testing
El viernes, 16 de octubre de 2015, a las 00:23 UTC Gonzalo Rivero escribió: > El día 15 de octubre de 2015, 6:26, Manolo Díaz > escribió: > > El jueves, 15 oct 2015 a las 00:40 UTC > > Gonzalo Rivero escribió: > > > > > >> [27.212] (II) LoadModule: "nouveau" > >> [27.213] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so > >> [27.463] (II) Module nouveau: vendor="X.Org Foundation" > >> [27.464] (II) LoadModule: "nv" > >> [27.505] (II) UnloadModule: "nv" > >> [27.505] (II) Unloading nv > >> [27.505] (II) LoadModule: "modesetting" > >> [27.505] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > >> [27.566] (II) Module modesetting: vendor="X.Org Foundation" > >> [27.566] (II) LoadModule: "fbdev" > >> [27.567] (II) UnloadModule: "fbdev" > >> [27.567] (II) Unloading fbdev > >> [27.567] (II) LoadModule: "vesa" > >> [27.567] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so > >> [27.622] (II) Module vesa: vendor="X.Org Foundation" > > > > [...] > > > >> ¿por donde podría empezar a buscar? > >> > > > > Parece que prueba los controladores para nouveau, nv, framebuffer y > > VESA, y que finalmente se decide por este último. Se me ocurren dos > > cosas que intentar: > > > > Desinstalar los controladores VESA. > > > > Crear un archivo de configuración mínimo que contenga la sección > > "Device" donde indicas que el controlador es nouveau. > > > > > intenté eso pero al arrancar las X se quejó que no encontraba > pantalla. Al menos ya tengo por donde empezar a buscar que leer: como > se hacía el archivo de configuración completo... > es la mala costumbre de que las cosas anden y en pocos intentos, uno > se va oxidando con los años jejeje > No necesitas un fichero con la configuración entera. Yo tengo un par en /etc/X11/xorg.conf.d/, cada uno con una única sección. Y no se queja de que no encuentra pantalla aunque yo no la defino en ninguna. Los nombres de los ficheros pueden ser arbitrarios, pero acabados en .conf -- Manolo Díaz
Re: problemas con nouveau en testing
El jueves, 15 oct 2015 a las 00:40 UTC Gonzalo Rivero escribió: > [27.212] (II) LoadModule: "nouveau" > [27.213] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so > [27.463] (II) Module nouveau: vendor="X.Org Foundation" > [27.464] (II) LoadModule: "nv" > [27.505] (II) UnloadModule: "nv" > [27.505] (II) Unloading nv > [27.505] (II) LoadModule: "modesetting" > [27.505] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > [27.566] (II) Module modesetting: vendor="X.Org Foundation" > [27.566] (II) LoadModule: "fbdev" > [27.567] (II) UnloadModule: "fbdev" > [27.567] (II) Unloading fbdev > [27.567] (II) LoadModule: "vesa" > [27.567] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so > [27.622] (II) Module vesa: vendor="X.Org Foundation" [...] > ¿por donde podría empezar a buscar? > Parece que prueba los controladores para nouveau, nv, framebuffer y VESA, y que finalmente se decide por este último. Se me ocurren dos cosas que intentar: Desinstalar los controladores VESA. Crear un archivo de configuración mínimo que contenga la sección "Device" donde indicas que el controlador es nouveau. En cualquier caso, diría que has encontrado un fallo. -- Manolo Díaz
Re: Cambiar de kernel en Jessie
El lunes, 12 oct 2015 a las 08:20 UTC Josu Lazkano escribió: > Hola a todos, > > Me acabo de dar cuenta que tengo instala la version 4.1 del kernel en Jessie. > > Tengo el repositorio de backport añadido: > > # cat /etc/apt/sources.list > deb http://mirrors.kernel.org/debian/ jessie main contrib non-free > deb-src http://mirrors.kernel.org/debian/ jessie main contrib non-free > > deb http://security.debian.org/ jessie/updates main > deb-src http://security.debian.org/ jessie/updates main > > # jessie-updates, previously known as 'volatile' > deb http://mirrors.kernel.org/debian/ jessie-updates main > deb-src http://mirrors.kernel.org/debian/ jessie-updates main > > # jessie-backports, previously on backports.debian.org > deb http://mirrors.kernel.org/debian/ jessie-backports main > deb-src http://mirrors.kernel.org/debian/ jessie-backports main > > #deb-multimedia.org > deb http://deb-multimedia.org jessie main non-free > deb-src http://deb-multimedia.org jessie main non-free > > #deb-multimedia.org backports > deb http://deb-multimedia.org jessie-backports main > deb-src http://deb-multimedia.org jessie-backports main > > El kernel que tengo es el siguiente: > > # uname -a > Linux server 4.1.0-900-amd64 #1 SMP Debian 4.1.6-1~bpo8+1 (2015-09-09) > x86_64 GNU/Linux > > ¿Como puedo volver al kernel 3.16? linux-image-3.16 > Lo malo de la 4.1 es que no tengo las sources. linux-source-4.1 > Gracias por todo y un saludo. -- Manolo Díaz
Re: ¿Es peligroso borrar los transitional dummy packages?
El domingo, 11 oct 2015 a las 18:50 UTC Eduardo Rios escribió: > Hola > Hoy estaba aburrido en casa, y he pensado en hacer un poco de "limpieza" > de mi Debian Stretch, ya que el sistema se ha ido actualizando desde > Debian Squeeze (creo que es la única que instalé en limpio). > > Lo primero que he desinstalado han sido los paquetes gpp y gcc de las > versiones 4.8 y 4.9, ya que está instalada la versión 5.0 de estos. > > Después, he buscado los paquetes "transitional dummy packages y los he > eliminado (siempre que se dejaban borrar ellos solos y no marcaban otras > dependencias para borrar) > > Aparentemente el sistema funciona con normalidad. ¿Es una locura lo que > acabo de hacer? No. Si todavía algún paquete depende de él te lo advertirá. Como alternativa, yo suelo tenerlos marcado como de instalación automática (apt-mark auto el_paquete_que_sea) y cuando ningún otro depende de él, el sistema de paquetes me sugiere desinstalarlo. > Gracias. > -- Manolo Díaz
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
El domingo, 11 oct 2015 a las 06:10 UTC Frederit Mogollon escribió: > Lo que llevo hecho: > > 1/ Cambié los comandos /sbin/shutdown, /sbin/reboot y /sbin/halt al > grupo salir: > > # chgrp salir /sbin/shutdown /sbin/reboot /sbin/halt > > 2/ Dí permisos de ejecución a los comandos /sbin/shutdown y /sbin/halt: > > # chmod u+s,o-rwx /sbin/shutdown /sbin/halt > > 3/ Revisé el estado de los permisos para estos comandos: [...] > root@Tesistas:/home/tesistas# ls -l /sbin/shutdown > -rwSr- 1 tesistas salir 22192 abr 27 00:48 /sbin/shutdown [...] > root@Tesistas:/home/tesistas# ls -l /sbin/halt > -rwSr- 1 tesistas salir 13848 abr 27 00:49 /sbin/halt [...] > - Sigo sin poder apagar/reiniciar como usuario normal ni como > superusuario. No tengo permisos. Efectivamente, no tienes permiso de ejecución para nadie en esos dos ejecutables: tienes el bit setuid pero no permiso de ejecución para root (indicado por la S mayúscula). Por otro lado, ¿para qué cambiar el grupo si luego el grupo no tiene ningún permiso? ¿Has pensado en el enfoque de Ramses, dejar los permisos originales y utilizar sudo? -- Manolo Díaz
Re: linux de dos nucleos pasarlo a uno
El sábado, 10 oct 2015 a las 18:41 UTC Fabián Bonetti escribió: > On Sat, 10 Oct 2015 20:29:08 +0200 > Manolo Díaz wrote: > > > El sábado, 10 oct 2015 a las 18:19 UTC > > Fabián Bonetti escribió: > > > > > > > > Cambie de mother y micro... > > > > > > Antes tenia un doble nucleo ahora un micro nucleo simple > > > > > > pero me sigue apareciendo como si tuviera dos nucleos > > > > > > Antes tenia un E2160 dual core de 1.8Ghz ahora un Pentium 4 nucleo simple > > > de 3Ghz > > > > > > Con este comando podia volver a que me tome un core solo. > > > > > > # echo 0 > /sys/devices/system/cpu/cpu1/online > > > > > > > > > Pero creo que se puede mejorar que al inicio arranque de manera adecuada > > > tomándome un solo core. > > > > > > Lo que me gustaria saber como hacer para que solo me tome un core... y no > > > dos. Ya que dispongo de un > > > > > > Pentium 4 nucleo simple de 3Ghz. > > > > Será un núcleo de doble hilo. No te preocupes que Linux no puede crear > > núcleos que no existan, déjalo como está. > > > > -- > > Manolo Díaz > > > > El sistema debian se instalo en doble nucleo... luego se le coloco nucleo > simple. No importa. > Siempre usando el mismo disco duro. > > Solo me molesta cuando uso top/htop > > y ahi pongo el comando manual > > # echo 0 > /sys/devices/system/cpu/cpu1/online ¿Qué molestia? Lo que ocurre es que está haciendo uso del Hyper Threading [1]. Déjalo estar o estarás desaprovechando una característica de tu procesador. https://es.wikipedia.org/wiki/HyperThreading -- Manolo Díaz
Re: linux de dos nucleos pasarlo a uno
El sábado, 10 oct 2015 a las 18:19 UTC Fabián Bonetti escribió: > > Cambie de mother y micro... > > Antes tenia un doble nucleo ahora un micro nucleo simple > > pero me sigue apareciendo como si tuviera dos nucleos > > Antes tenia un E2160 dual core de 1.8Ghz ahora un Pentium 4 nucleo simple de > 3Ghz > > Con este comando podia volver a que me tome un core solo. > > # echo 0 > /sys/devices/system/cpu/cpu1/online > > > Pero creo que se puede mejorar que al inicio arranque de manera adecuada > tomándome un solo core. > > Lo que me gustaria saber como hacer para que solo me tome un core... y no > dos. Ya que dispongo de un > > Pentium 4 nucleo simple de 3Ghz. Será un núcleo de doble hilo. No te preocupes que Linux no puede crear núcleos que no existan, déjalo como está. -- Manolo Díaz
Re: Debian deja el Linux Standard Base. :(
El sábado, 10 oct 2015 a las 16:22 UTC Camaleón escribió: > > Me gustaría ver una aplicación como Oracle Database 11g o 12c, > > cumpliendo con el estándar LSB, y pudiendo ser instalada sin > > inconvenientes en Oracle Linux, SuSE Linux, OpenSuSE, Ubuntu y por > > supuesto Debian, incluyendo por supuesto el soporte de Oracle, asi fuese > > de pago. > > (...) > > Mal ejemplo: algo me dice que Oracle Database es software propietario así > que no deberías ni tenerlo en cuenta siquiera como candidato a cumplir el > LSB ;-) Pues algo me dice a mí que no has entendido qué es el LSB. Porque, sea propietario o no, si se anuncia como compatible LSB debe poderse instalar sin más en cualquier distribución que también se proclame como tal. -- Manolo Díaz
Re: Debian deja el Linux Standard Base. :(
El sábado, 10 oct 2015 a las 14:31 UTC Camaleón escribió: > El Sat, 10 Oct 2015 13:45:05 +0200, Manolo Díaz escribió: > > > ¿Pena por qué? Solo hay 8 aplicaciones certificadas repartidas entre 6 > > empresas. ¿No te parece demasiado esfuerzo para tan pequeño logro? > > > > https://lwn.net/Articles/658289/ > > Es una pena lo mires por donde lo mires: > > 1/ Si LSB no sirve para nada, entonces la Linux Foundation está > destinando recursos a un proyecto que nadie usa y eso de traduce en una > pérdida de esos recursos que mejor podrían destinarse a otras iniciativas. Pues escríbeles y se lo cuentas. > 2/ Si LSB resulta útil y se abandona por falta de recursos/interés es que > Debian prefiere un sistema "quick & dirty" antes que mantenerse en la > liga donde juegan los mayores (distribuciones empresariales como Redhat o > SUSE Linux). > > Sinceramente, los estándares en informática siempre son útiles. Siempre que se usen. > Quo Vadis, Debian. > Saludos, https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb -- Manolo Díaz
Re: Debian Wheezy 7.9 sin permisos sobre el sistema después de actualización
El viernes, 9 oct 2015 a las 11:38 UTC Frederit Mogollon escribió: > > # shutdown -h now > bash: /usr/local/bin/shutdown: Permiso denegado > - > > # poweroff > bash: /sbin/poweroff: Permiso denegado > --- > --- > # reboot > bash: /usr/local/bin/reboot: Permiso denegado > ¿El sistema de ficheros está bien? ¿Has comprobado los permisos de alguno de esos ejecutables que te lo deniegan? -- Manolo Díaz
Re: Debian deja el Linux Standard Base. :(
El sábado, 10 oct 2015 a las 14:23 UTC Santiago José López Borrazás escribió: > El 10/10/15 a las 16:13, Manolo Díaz escribió: > > No. > > Depende de cómo lo miremos. > No, no es algo relativo. ¿Tienes una de esas, al parecer, muy escasas aplicaciones instalable en todas las distribuciones compatibles con LSB? Porque si todo lo que tienes instalado proviene de los repositorios de Debian ni vas a notar el cambio. -- Manolo Díaz
Re: Debian deja el Linux Standard Base. :(
El sábado, 10 oct 2015 a las 14:04 UTC Santiago José López Borrazás escribió: > > Entonces si es malo... porque influirá en el firmware necesario para > > dispositivos como tarjetas de red wifi... ¿no? > > Si es de código privativo, sí. No. -- Manolo Díaz
Re: Debian deja el Linux Standard Base. :(
El sábado, 10 oct 2015 a las 11:53 UTC Santiago José López Borrazás escribió: > El 10/10/15 a las 13:45, Manolo Díaz escribió: > > ¿Pena por qué? Solo hay 8 aplicaciones certificadas repartidas entre 6 > > empresas. ¿No te parece demasiado esfuerzo para tan pequeño logro? > > Es por las librerías compartidas que comentan. ¿Te refieres a esto? "Linus Torvalds por su parte, considera que Debian utiliza bibliotecas compartidas. Esto implica, que si uno tiene en su software algunas que son experimentales, puede ser un gran problema." Así que Linus considera que Debian utiliza bibliotecas compartidas. También yo lo considero. Al igual que las usa el resto de las distribuciones, Windows y OS X. La meta de LSB era que cada aplicación que la cumpliese funcionase en cada distribución compatible, pero parece que se ha quedado en intento. -- Manolo Díaz
Re: Debian deja el Linux Standard Base. :(
El sábado, 10 oct 2015 a las 11:19 UTC Santiago José López Borrazás escribió: > Leído ahora mismo, pues hace horas que lo han publicado: > > http://hipertextual.com/2015/10/debian-abandona-linux-standard-base > > Y...hay más cosas... > > Es una pena. :( ¿Pena por qué? Solo hay 8 aplicaciones certificadas repartidas entre 6 empresas. ¿No te parece demasiado esfuerzo para tan pequeño logro? https://lwn.net/Articles/658289/ -- Manolo Díaz
Re: Cosas raras pasan en las Xorg con Plasma
El sábado, 10 oct 2015 a las 07:40 UTC BasaBuru escribió: [...] > Bueno, lo primero no necesitas xorg.conf esta deprecated, en la actualidad > autodecta automáticamente el hardware y lo configura, así como su > funcionamiento al cargar módulos. [...] > Sin Xorg.conf es dinámico, por ejemplo puedes cambiar en caliente el > renderizado xorg.conf es más versátil de lo que das a entender. Puede usarse para personalizar la configuración sin necesidad de detallarla al completo. Por ejemplo, yo uso uno de solo 6 líneas para que no active nunca el sistema de ahorro energético. Para el resto de opciones doy por buena la configuración automática. Y puedo cambiar en caliente parámetros como resolución, frecuencia de actualización, etc. -- Manolo Díaz
Re: Obtener $HOSTNAME sin iniciar sesión.
El viernes, 9 oct 2015 a las 15:15 UTC Ramses escribió: > El 9 de octubre de 2015 17:00:46 CEST, "Manolo Díaz" > escribió: > >El viernes, 9 oct 2015 a las 14:58 UTC > >Ramses escribió: > > > >> El 9 de octubre de 2015 16:19:58 CEST, "Manolo Díaz" > > escribió: > >> >El viernes, 9 oct 2015 a las 05:32 UTC > >> >Aaron D. escribió: > >> > > >> >> On Fri, Oct 09, 2015 at 01:39:32AM +0200, Ramses wrote: > >> >> > Buenas noches, > >> >> > > >> >> > Si desde una sesión SSH ejecuto: > >> >> > > >> >> > echo $HOSTNAME > fichero.txt > >> >> > > >> >> > Me introduce sin problemas el nombre de la máquina en el fichero > >> >fichero.txt > >> >> > > >> >> > El problema lo tengo cuando introduzco esa línea en el fichero > >> >/etc/rc.local para que se ejecute cuando arranca la máquina, que > >genera > >> >el fichero.txt, pero en blanco. > >> >> > > >> >> > ¿Cómo podría generar ese fichero con el contenido de esa > >variable? > >> > > >> >Con la orden hostname. > >> > > >> >> > Sé que podría sacarlo desde /etc/hostname, pero me causa > >curiosidad > >> >que no lo genere al poner esa línea en el rc.local. > >> >> > > >> >> > Otra duda: Al hacer un printenv no aparece la variable HOSTNAME. > >> >¿En qué entorno está esa variable?. > >> >> > > >> >> > > >> >> > Saludos y gracias, > >> >> > > >> >> > Ramses > >> >> > > >> >> > >> >> Supongo que será porque cuando ejecuta rc.local aún no ha > >levantado > >> >el servicio que asigne el hostname. > >> > > >> >Creo que no. rc.local es el último de los servicios en lanzarse, o > >al > >> >menos es lo predeterminado. Diría que ese script se lanza desde un > >> >entorno en que HOSTNAME no está asignada o no se exporta. > >> > >> Manolo, muchas gracias por la info... > >> > >> Pero, por ejemplo, lo que estoy intentando hacer es: > >> > >> echo "Equipo: " $HOSTNAME | mail -s "Envio desde " $HOSTNAME > >m...@correo.es > >> > >> Eso me llega bien desde la Consola, ¿pero como podría hacerlo con el > >comando 'hostname' en esa línea? > >> > >> > >> Saludos y gracias, > >> > >> Ramses > >> > > > >Con una sustitución de orden > > > > > > > >a partir de ahora esa variable tendrá el valor que quieres. > > > >Saludos. > > Sí, ¿pero sin meterlo en una variable?, ¿cómo podría hacerlo para que envíe > la salida del comando 'hostname' incluyendo el comando en la misma línea del > "echo."? > > > Saludos, > > Ramses > Ramses, exactamente igual. La diferencia es que tendría que ejecutar la misma orden dos veces echo "Equipo: " `hostname` | mail -s "Envio desde " `hostname` ¿Qué problema tiene meterlo en una variable? ¿Cómo si no iba a funcionar $HOSTNAME si no almacena nada? -- Manolo Díaz
Re: Obtener $HOSTNAME sin iniciar sesión.
El viernes, 9 oct 2015 a las 14:58 UTC Ramses escribió: > El 9 de octubre de 2015 16:19:58 CEST, "Manolo Díaz" > escribió: > >El viernes, 9 oct 2015 a las 05:32 UTC > >Aaron D. escribió: > > > >> On Fri, Oct 09, 2015 at 01:39:32AM +0200, Ramses wrote: > >> > Buenas noches, > >> > > >> > Si desde una sesión SSH ejecuto: > >> > > >> > echo $HOSTNAME > fichero.txt > >> > > >> > Me introduce sin problemas el nombre de la máquina en el fichero > >fichero.txt > >> > > >> > El problema lo tengo cuando introduzco esa línea en el fichero > >/etc/rc.local para que se ejecute cuando arranca la máquina, que genera > >el fichero.txt, pero en blanco. > >> > > >> > ¿Cómo podría generar ese fichero con el contenido de esa variable? > > > >Con la orden hostname. > > > >> > Sé que podría sacarlo desde /etc/hostname, pero me causa curiosidad > >que no lo genere al poner esa línea en el rc.local. > >> > > >> > Otra duda: Al hacer un printenv no aparece la variable HOSTNAME. > >¿En qué entorno está esa variable?. > >> > > >> > > >> > Saludos y gracias, > >> > > >> > Ramses > >> > > >> > >> Supongo que será porque cuando ejecuta rc.local aún no ha levantado > >el servicio que asigne el hostname. > > > >Creo que no. rc.local es el último de los servicios en lanzarse, o al > >menos es lo predeterminado. Diría que ese script se lanza desde un > >entorno en que HOSTNAME no está asignada o no se exporta. > > Manolo, muchas gracias por la info... > > Pero, por ejemplo, lo que estoy intentando hacer es: > > echo "Equipo: " $HOSTNAME | mail -s "Envio desde " $HOSTNAME m...@correo.es > > Eso me llega bien desde la Consola, ¿pero como podría hacerlo con el comando > 'hostname' en esa línea? > > > Saludos y gracias, > > Ramses > Con una sustitución de orden HOSTNAME=`hostname` a partir de ahora esa variable tendrá el valor que quieres. Saludos. -- Manolo Díaz
Re: Obtener $HOSTNAME sin iniciar sesión.
El viernes, 9 oct 2015 a las 05:32 UTC Aaron D. escribió: > On Fri, Oct 09, 2015 at 01:39:32AM +0200, Ramses wrote: > > Buenas noches, > > > > Si desde una sesión SSH ejecuto: > > > > echo $HOSTNAME > fichero.txt > > > > Me introduce sin problemas el nombre de la máquina en el fichero fichero.txt > > > > El problema lo tengo cuando introduzco esa línea en el fichero > > /etc/rc.local para que se ejecute cuando arranca la máquina, que genera el > > fichero.txt, pero en blanco. > > > > ¿Cómo podría generar ese fichero con el contenido de esa variable? Con la orden hostname. > > Sé que podría sacarlo desde /etc/hostname, pero me causa curiosidad que no > > lo genere al poner esa línea en el rc.local. > > > > Otra duda: Al hacer un printenv no aparece la variable HOSTNAME. ¿En qué > > entorno está esa variable?. > > > > > > Saludos y gracias, > > > > Ramses > > > > Supongo que será porque cuando ejecuta rc.local aún no ha levantado el > servicio que asigne el hostname. Creo que no. rc.local es el último de los servicios en lanzarse, o al menos es lo predeterminado. Diría que ese script se lanza desde un entorno en que HOSTNAME no está asignada o no se exporta. -- Manolo Díaz
Re: mostrar la ruta completa
El jueves, 8 oct 2015 a las 19:19 UTC listascor...@msjs.co escribió: > Lo que quiero es buscar recursivamente en un directorio todos los > enlaces y la salida muestre la dirección completa del enlace y > seguidamente la dirección completa del archivo enlazado. IFS=$'\t\n' for i in `find DIRECTORIO_A_TRATAR -type l` do echo $i - `readlink -m $i` done Ten en cuenta dos cosas: La primera línea es un bashismo. Si quieres que funcione en cualquier intérprete POSIX (dash, p. ej.) debes cambiar IFS. Puedes necesitar devolverle el valor antiguo si el script hace más cosas. También puedes prescindir de esa primera línea si los nombres de los enlaces no contienen espacio. El fichero apuntado por el enlace puede no existir aunque se muestre su nombre. Si no es lo que quieres mira el man de readlink. -- Manolo Díaz
Re: no se usan todos los recursos de hardware
El jueves, 8 oct 2015 a las 07:17 UTC Darthcoli - Alejandro Izquierdo escribió: > y todos tienen configurado como scheduler un CFQ. Pero no he > caído en abordar el problema por esa vía, y voy a realizar pruebas con > otros scheduler (gracias por la sugerencia, camaleón) Más sencillo que eso es probar la sugerencia de Fernando, la de ejecutar varios yes, por el sencillo motivo de que no hace escritura en disco y zanja de una vez por todas si ese es el problema. -- Manolo Díaz
Re: [OT] Grafear chequeos nagios personalizados
El miércoles, 7 oct 2015 a las 13:52 UTC
Maykel Franco escribió:
> El día 7 de octubre de 2015, 10:40, Manolo Díaz
> escribió:
> > El miércoles, 7 oct 2015 a las 07:50 UTC
> > Maykel Franco escribió:
> >
> >> Hola buenas, finalmente me he decantado por usar nagios a pelo y hacer
> >> mis propios scripts de chequeo cuando los necesite. Por ejemplo he
> >> realizado uno para comprobar el número de Threads que tiene la
> >> máquina, de esta forma, algo sencillo:
> >>
> >> #!/bin/bash
> >>
> >> threads=`grep -s '^Threads' /proc/[0-9]*/status | awk '{ sum += $2; }
> >> END { print sum; }'`
> >>
> >> if [ $threads -lt 2000 ] ; then
> >> status=0
> >> statustxt=OK
> >> elif [ $threads -lt 3000 ] ; then
> >> status=1
> >> statustxt=WARNING
> >> else
> >> status=2
> >> statustxt=CRITICAL
> >> fi
> >> echo "THREADS $statustxt - $threads threads ;2000;3000;0; | Number
> >> Threads $threads"
> >>
> >> El problema que tengo es que pnp4nagios no grafea... No crea si quiera
> >> el gráfico rrd...
> >>
> >> Si lo ejecuto, me devuelve esto:
> >>
> >> THREADS OK - 762 threads ;2000;3000;0; | Number Threads 762
> >>
> >> Según la doc de nagios y de pnp4nagios:
> >>
> >> https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/perfdata.html
> >>
> >> http://docs.pnp4nagios.org/pnp-0.6/perfdata_format
> >>
> >> Creo que devuelvo lo que necesita para grafear pero no lo hace...
> >>
> >> Alguien tiene alguna idea?
> >
> > Pues según uno de los enlaces
> >
> > Performance data is defined by Nagios as “everything after the | of
> > the plugin output”
> >
> > Es decir, creo que inviertes el orden, los datos a dibujar van después
> > de la barra vertical.
> >
> >> Uso nagios 4.1.1 + NRPE + pnp4nagios
> >>
> >> Gracias de antemano.
> >
> > --
> > Manolo Díaz
> >
>
> Te refieres así??
>
> THREADS OK - 762 threads | Number Threads 762 ;2000;3000;0;
>
Después de la barra vertical
'Number Treads'=762;;2000;3000;0;
Incluida comillas simples. No se especifica máximo.
--
Manolo Díaz
Re: [OT] Grafear chequeos nagios personalizados
El miércoles, 7 oct 2015 a las 07:50 UTC
Maykel Franco escribió:
> Hola buenas, finalmente me he decantado por usar nagios a pelo y hacer
> mis propios scripts de chequeo cuando los necesite. Por ejemplo he
> realizado uno para comprobar el número de Threads que tiene la
> máquina, de esta forma, algo sencillo:
>
> #!/bin/bash
>
> threads=`grep -s '^Threads' /proc/[0-9]*/status | awk '{ sum += $2; }
> END { print sum; }'`
>
> if [ $threads -lt 2000 ] ; then
> status=0
> statustxt=OK
> elif [ $threads -lt 3000 ] ; then
> status=1
> statustxt=WARNING
> else
> status=2
> statustxt=CRITICAL
> fi
> echo "THREADS $statustxt - $threads threads ;2000;3000;0; | Number
> Threads $threads"
>
> El problema que tengo es que pnp4nagios no grafea... No crea si quiera
> el gráfico rrd...
>
> Si lo ejecuto, me devuelve esto:
>
> THREADS OK - 762 threads ;2000;3000;0; | Number Threads 762
>
> Según la doc de nagios y de pnp4nagios:
>
> https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/perfdata.html
>
> http://docs.pnp4nagios.org/pnp-0.6/perfdata_format
>
> Creo que devuelvo lo que necesita para grafear pero no lo hace...
>
> Alguien tiene alguna idea?
Pues según uno de los enlaces
Performance data is defined by Nagios as “everything after the | of
the plugin output”
Es decir, creo que inviertes el orden, los datos a dibujar van después
de la barra vertical.
> Uso nagios 4.1.1 + NRPE + pnp4nagios
>
> Gracias de antemano.
--
Manolo Díaz
Re: Interfaces de red
El martes, 6 oct 2015 a las 12:14 UTC José Maldonado escribió: > Sobre lo de accesibilidad tienes razón los lectores de pantalla son > secuenciales y es molesto andar pasando cientos de lineas para poder llegar > a la respuesta que te han dado [...] Quizá él tenga una memoria de elefante, pero otras menos desarrolladas, como la mía, necesita ponerse en antecedentes para ver a qué responde. Tal vez lo más sencillo sea suprimir todo aquello que no tiene relación con la respuesta, como han sugerido en este hilo. > Pero hay un reglamento para lista, y no es perfecto como en tu caso se ha > podido observar, creo que es mejor en estos casos obviarlo y responder con > él molesto top posting que a Camaleón le molesta tanto, no te preocupes > ella es asi con todo el mundo. No, no es solo cosa de Camaleón. A muchos nos molesta. Por algo las ediciones comienzan por el primer capítulo y terminan con el último. En cuanto al reglamento, no es sagrado: si un cambio está justificado se hace. -- Manolo Díaz
Re: no se usan todos los recursos de hardware
El martes, 6 oct 2015 a las 13:08 UTC Darthcoli - Alejandro Izquierdo escribió: > Hola. Ante todo un saludo, soy nuevo y hace poco me apunte a esta lista. > Quiero estrenarme lanzando una consulta que arrastro hace tiempo, es una > situación que veo a menudo y que nunca he conseguido entender. > > Pongo un ejemplo: tengo un sencillo script en bash que lee un archivo de > texto y compara lineas de texto. El script no hace nada mal o complicado ni > entra en bucles ni nada parecido. Sin embargo siempre consume la misma cpu > (aprox un 10%) y tampoco genera elevadas tasas de IO, sobran gb de ram. > > He probado en diferentes maquinas! he probado a cambiar la prioridad con > renice. > > ¿Por que? ¿Por que no usa toda la cpu? ¿Por que si tiene recursos libres de > sobra no los usa? > > Muchas gracias y saludo > ¿Usas algún tipo de cuota de CPU para los usuarios? Cgroups es capaz de cosas así. -- Manolo Díaz
Re: [OT] Certificados autofirmados en apache
El martes, 6 oct 2015 a las 13:51 UTC Camaleón escribió: > El Tue, 06 Oct 2015 09:56:22 +0200, Manolo Díaz escribió: > > > El martes, 6 oct 2015 a las 07:38 UTC Maykel Franco escribió: > > > >> El día 5 de octubre de 2015, 18:40, Camaleón > >> escribió: > > (...) > > >> >> Con qué entidad puedo solicitarlos o a qué te refieres?? > >> > > >> > (...) > >> > > >> > Echa un vistazo a estos dos proyectos (no sé si habrá alguno más): > >> > > >> > https://letsencrypt.org/ > >> > http://www.cacert.org/ > > (...) > > >> Gracias por las respuestas. > >> > >> He leído que StartSSL (startssl.com), que ofrece certificados gratuitos > >> válidos y reconocidos por una CA de confianza en los packs de > >> certificados habituales... > > > > Pues Iceweasel no me los muestra. Asegúrate de que lo tienes en tus > > clientes o estarás en las mismas. > > ¿A qué te refieres? :-? > > A mí me carga la página web bajo SSL¹ sin mostrarme ningún aviso, tanto > en Firefox 41.0.1 como en Iceweasel (testing). > > ¹https://www.startssl.com/?app=12 > > Saludos, No, a mí tampoco me da problemas. Los certificados de la autoridad certificadora StartCom (y no StarSSL como se dijo antes) sí que vienen de serie en el paquete ca-certificates, por lo que al menos en Debian no debe tener problemas. -- Manolo Díaz
Re: [OT] Ajustar ToS mediante nftables
El martes, 6 oct 2015 a las 13:30 UTC Camaleón escribió: > El Mon, 05 Oct 2015 20:10:22 +0200, Manolo Díaz escribió: > > > El lunes, 5 oct 2015 a las 17:51 UTC Camaleón escribió: > > > >> El Mon, 05 Oct 2015 19:20:12 +0200, Manolo Díaz escribió: > >> > >> > El lunes, 5 oct 2015 a las 17:01 UTC Camaleón escribió: > >> > >> (...) > >> > >> > Respuesta a la orden, copia exacta: > >> > > >> > :1:53-55: Error: syntax error, unexpected set add rule ip > >> > mangle postrouting udp dport ntp ip tos set 0x10 > >> > ^^^ > >> > >> No he leído el manual pero parece que ese operador (set) no está > >> permitido ahí. > > > > set se usa para describir conjuntos pero también para ajustar valores. > > Ese y otros intentos míos están inspirados en la forma de ajustar mark, > > priority y nftrace, al no encontrar documentación específica. Palos de > > ciego, por expresarlo de una forma clara y resumida. > > > > http://wiki.nftables.org/wiki-nftables/index.php/ > Setting_packet_metainformation > > El mensaje que te daba parece muy claro y coincido con el log en que > "tos" no admite "set". Es posible que otros valores sí lo admitan como > pone la wiki. > > >> Google sugiere que asignes el valor directamente: > >> > >> nft add rule ip mangle postrouting udp dport ntp ip tos 0x10 > > > > :1:1-56: Error: Could not process rule: No such file or > > directory > > add rule ip mangle postrouting udp dport ntp ip tos 0x10 > > > > Bien, al menos ya no se queja por el "set". Puedes fijarte en otros > ejemplos que usan "tos" para los paquetes, por ejemplo, este es un bug: > > http://lists.netfilter.org/pipermail/netfilter-buglog/2014-May/003179.html > > Quizá el problema lo tengas con el valor de tos, yo empezaría a añadir > reglas sencillas (como las que ponen en los ejemplos) a la tabla que > tienes definida para ver si eso funciona ya que de lo contrario es > posible que la tabla esté mal definida/estructurada ¿la has creado > manualmente o has usado la que viene en algún ejemplo de la documentación > del paquete, de alguna web...? Modificando la que trae el paquete nftables: /etc/nftables.conf El filtrado, tanto IP como ARP, me funciona perfectamente. Puedo seleccionar los paquetes por sus características (incluido ToS) y también puedo marcarlos. Lo único que no he conseguido es alterar el valor de un campo. Y el hecho de que no haya visto ni la más leve indicación de cómo hacerlo hasta ahora y que una búsqueda del patrón MANGLE en el fichero de configuración del núcleo Linux (4.2.1) solo encuentre coincidencia relacionada con iptables me hace pensar que es uno de los objetivos por cumplir de nftables. > Por ejemplo, de la página de la wiki que envías más arriba prueba con la > tabla que van generando con los comandos en la sección de "priority". > Crea la tabla y al final intenta añadir el valor tos como idnican pero > ajustándolo a tu regla: > > nft add rule mangle postrouting udp dport 123 tos 0x10 :1:43-45: Error: syntax error, unexpected tos, expecting end of file or newline or semicolon add rule mangle postrouting udp dport 123 tos 0x10 ^^^ Camaleón, te agradezco el esfuerzo, pero voy a abandonar el asunto a la espera de nuevas versiones del núcleo. > Saludos, Saludos. -- Manolo Díaz
Re: [OT] Certificados autofirmados en apache
El martes, 6 oct 2015 a las 07:38 UTC Maykel Franco escribió: > El día 5 de octubre de 2015, 18:40, Camaleón escribió: > > El Mon, 05 Oct 2015 18:22:57 +0200, Maykel Franco escribió: > > [...] > >> Certificados gratuitos?? Que no da error desde el cliente, en este caso > >> el navegador no?? > >> > >> Con qué entidad puedo solicitarlos o a qué te refieres?? > > > > (...) > > > > Echa un vistazo a estos dos proyectos (no sé si habrá alguno más): > > > > https://letsencrypt.org/ > > http://www.cacert.org/ > > > > Aunque las dos entidades certificadoras no están incluidas en todos los > > navegadores, cuidadín, pero siempre será mejor un error de entidad > > desconocida" que otro de certificado autofirmado" :-) > > > > De todas formas, los certificados reconocidos y que no te dan problemas > > con ningún navegador tampoco son tan caros. En su día usaba el de RapidSSL > > para la web (https) y el correo electrónico (imaps/pops/smtps+tls) por 50 > > $/año. > > > Gracias por las respuestas. > > He leído que StartSSL (startssl.com), que ofrece certificados > gratuitos válidos y reconocidos por una CA de confianza en los packs > de certificados habituales... Pues Iceweasel no me los muestra. Asegúrate de que lo tienes en tus clientes o estarás en las mismas. -- Manolo Díaz
Re: [OT] Ajustar ToS mediante nftables
El lunes, 5 oct 2015 a las 17:51 UTC Camaleón escribió: > El Mon, 05 Oct 2015 19:20:12 +0200, Manolo Díaz escribió: > > > El lunes, 5 oct 2015 a las 17:01 UTC Camaleón escribió: > > (...) > > > Respuesta a la orden, copia exacta: > > > > :1:53-55: Error: syntax error, unexpected set > > add rule ip mangle postrouting udp dport ntp ip tos set 0x10 > > ^^^ > > No he leído el manual pero parece que ese operador (set) no está > permitido ahí. set se usa para describir conjuntos pero también para ajustar valores. Ese y otros intentos míos están inspirados en la forma de ajustar mark, priority y nftrace, al no encontrar documentación específica. Palos de ciego, por expresarlo de una forma clara y resumida. http://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_metainformation > Google sugiere que asignes el valor directamente: > > nft add rule ip mangle postrouting udp dport ntp ip tos 0x10 :1:1-56: Error: Could not process rule: No such file or directory add rule ip mangle postrouting udp dport ntp ip tos 0x10 ^^^^ > Saludos, Saludos. -- Manolo Díaz
Re: [OT] Ajustar ToS mediante nftables
El lunes, 5 oct 2015 a las 17:01 UTC Camaleón escribió: > El Mon, 05 Oct 2015 18:31:53 +0200, Manolo Díaz escribió: > > > El lunes, 5 oct 2015 a las 14:06 UTC Camaleón escribió: > > > >> El Sun, 04 Oct 2015 21:01:49 +0200, Manolo Díaz escribió: > >> > >> > Estoy intentando modificar el campo ToS usando nftables 0.5-1. > > (...) > > >> > nft add rule ip mangle postrouting udp dport ntp ip tos set 0x10 > >> > > >> > fracasan, y búsquedas en internet solo me devuelven las incompletas > >> > página man y wiki de nft o cómo hacerlo con iptables. > >> > >> ¿Y qué error te da, de sintaxis o de otro tipo (concepto)? > > > > De sintaxis, pero eso ayuda poco. Sé que es posible seleccionar paquetes > > con un valor dado de ToS, por lo que tal vez nftables "cree" > > erróneamente que pretendo esto último y echa de más un "set" en la > > regla. > > ¿Y tenemos que adivinar lo que te devuelve? ;-) Respuesta a la orden, copia exacta: :1:53-55: Error: syntax error, unexpected set add rule ip mangle postrouting udp dport ntp ip tos set 0x10 ^^^ > >> > ¿Sabe alguien si lo que intento es siquiera posible en el actual > >> > estado de nftables? > >> > >> Ni idea... ¿has preguntando en su lista? > >> > >> http://netfilter.org/mailinglists.html#ml-user > > > > Personalmente no, pero hay una similar (pregunta si es posible cambiar > > el valor DSCP) de diciembre pasado que ha quedado sin contestar: > > https://marc.info/?l=timekeepers&m=141932348110255&w=4 > > Esa lista de de NTP, no veo qué relación tiene con nftables (?). No me había dado cuenta. Ocurre que el enlace para navegar el archivo actual de la lista te lleva a un buscador de varias listas diferentes. Lo que hacía falta. > Saludos, Saludos. -- Manolo Díaz
Re: [OT] Certificados autofirmados en apache
El lunes, 5 oct 2015 a las 16:22 UTC Maykel Franco escribió: > >> Mi pregunta es, se puede de alguna forma, internamente (dns interno) o > >> jugando con la configuración de apache hacer que no de ese error en el > >> navegador web?? Quizá importando en el cliente que se conecta el > >> certificado trust ca o algo así? > > > > No, al menos yo no sé de ninguna opción para eso. Ten en cuenta que > > depende de la configuración del navegador y del sistema operativo de cada > > usuario, algo que no puedes controlar desde un servidor. > > Ya ya lo imaginaba, pero lo mismo se podía hacer algo más desde la > parte del cliente. Puedes instalar el certificado de la CA y darle confianza para servicios web _en cada cliente_. -- Manolo Díaz
Re: [OT] Ajustar ToS mediante nftables
El lunes, 5 oct 2015 a las 14:06 UTC
Camaleón escribió:
> El Sun, 04 Oct 2015 21:01:49 +0200, Manolo Díaz escribió:
>
> > Estoy intentando modificar el campo ToS usando nftables 0.5-1.
>
> nftables está en desarrollo.
>
> > Dada la tabla correctamente establecida
> >
> > table ip mangle {
> > chain postrouting {
> > type route hook output priority -150;
> >
> > }
> > }
> >
> > intentos similares a
> >
> > nft add rule ip mangle postrouting udp dport ntp ip tos set 0x10
> >
> > fracasan, y búsquedas en internet solo me devuelven las incompletas
> > página man y wiki de nft o cómo hacerlo con iptables.
>
> ¿Y qué error te da, de sintaxis o de otro tipo (concepto)?
De sintaxis, pero eso ayuda poco. Sé que es posible seleccionar paquetes
con un valor dado de ToS, por lo que tal vez nftables "cree"
erróneamente que pretendo esto último y echa de más un "set" en la
regla.
> > ¿Sabe alguien si lo que intento es siquiera posible en el actual estado
> > de nftables?
>
> Ni idea... ¿has preguntando en su lista?
>
> http://netfilter.org/mailinglists.html#ml-user
Personalmente no, pero hay una similar (pregunta si es posible cambiar
el valor DSCP) de diciembre pasado que ha quedado sin contestar:
https://marc.info/?l=timekeepers&m=141932348110255&w=4
> Saludos,
Saludos.
--
Manolo Díaz
[OT] Ajustar ToS mediante nftables
Saludos:
Estoy intentando modificar el campo ToS usando nftables 0.5-1.
Dada la tabla correctamente establecida
table ip mangle {
chain postrouting {
type route hook output priority -150;
}
}
intentos similares a
nft add rule ip mangle postrouting udp dport ntp ip tos set 0x10
fracasan, y búsquedas en internet solo me devuelven las incompletas
página man y wiki de nft o cómo hacerlo con iptables.
¿Sabe alguien si lo que intento es siquiera posible en el actual estado
de nftables?
--
Manolo Díaz
Re: [Fwd: Re: Debian deja de dar soporte a procesadores < i686]
El viernes, 2 oct 2015 a las 13:51 UTC Javier ArgentinaBBAR escribió: > P: ¿Cuántos diseñadores de Pentium se necesitan para cambiar una bombilla? > R: 0.99904274017. Pero no importa, es bastante aproximado para los que > no son técnicos. ¿En serio presentaba un error de aproximadamente un uno por mil en sus cálculos? -- Manolo Díaz
Re: egrep en castellano vs egrep en inglés
El miércoles, 30 sep 2015 a las 16:28 UTC Camaleón escribió: > El Wed, 30 Sep 2015 18:20:58 +0200, Manolo Díaz escribió: > > > El miércoles, 30 sep 2015 a las 15:45 UTC Camaleón escribió: > > > >> El Wed, 30 Sep 2015 17:13:13 +0200, Manolo Díaz escribió: > >> > >> > El miércoles, 30 sep 2015 a las 14:31 UTC Camaleón escribió: > >> > > >> >> Buscando en Google he visto que esta "característica" está > >> >> documentada en la versión de grep que tienes (2.21), vamos, que ni > >> >> bug ni fantasmas ni gaitas... misterio resuelto: > >> >> > >> >> http://savannah.gnu.org/forum/forum.php?forum_id=8152 > >> >> > >> >> If a file contains data improperly encoded for the current locale, > >> >> and this is discovered before any of the file's contents are output, > >> >> grep now treats the file as binary. > >> >> > >> >> > >> > Extraño. Así que caracteres que son inválidos en utf8 pueden no serlo > >> > en C. Creía que el último era un subconjunto de cualquier otro. > >> > >> Lo que sucede es que el archivo "passwd" está codificado en "iso-8859" > >> y grep está usando utf-8 de ahí que lo interprete mal y en la nueva > >> versión te lo detecta como binario. > > > > Por lo que sé está codificado en ascii. > > (...) > > No, la tabla de caracteres iso-8859 no es la misma que la tabla de > caracteres ascii, obviamente. ¿Y? Esas tablas son superconjuntos o ampliaciones de ascii (compatibilidad hacia atrás). Si un fichero, p.ej. /etc/passwd, pasa el test ascii, si solo contienen esos caracteres, por fuerza ha de pasar *cualquiera* de los test iso-8859-* y utf8. > Si un documento codificado en iso-8859-1 incluye un carácter que no está > en ascii N o lo conviertes a ascii o al leerlo te aparecen caracteres > extraños. Lo mismo pasa con utf-8 (quienes trabajan con archivos de texto > habitualmente sufren estos problemas en sus propias carnes). Ese es un caso distinto al que estamos tratando. De hecho es el caso inverso. > Saludos, Saludos -- Manolo Díaz
Re: Debian deja de dar soporte a procesadores < i686
El miércoles, 30 sep 2015 a las 15:38 UTC Sergio Bessopeanetto escribió: > El 30/09/15 a las 11:57, Camaleón escribió: > > Hola, > > > > Lo acabo de leer en la lista de desarrollo¹, parece que están decididos a > > dejar de mantener los procesadores i386/i486/i586 y se van a centrar en > > la arquitectura i686 (Pentium Pro/III/M). > > > > *** > > We propose to drop support for i386 processors older than 686-class in > > the current release cycle. This would include folding libc6-i686 into > > libc6, changing the default target for gcc, and changing the 586 kernel > > flavour to 686 (non-PAE). > > > > (...) > > > > The older processors would of course continue to be supported in jessie > > until at least 2018, and until 2020 if i386 is included in jessie LTS. > > *** > > > > Siempre da pena leer estas cosas pero sinceramente, podría ser peor. > > Parece que la última moda en linux es ir abandonando poco a poco la > > arquitectura de 32 bits en favor de la 64 bits y muchas distribuciones ya > > tienen puesto su punto de mira en implementar este cambio. Esperemos que > > Debian no siga ese camino o que lo haga un poquito más tarde :-) > > > > ¹https://lists.debian.org/debian-devel/2015/09/msg00589.html > > > > Saludos, > > > > Con esto se cae uno de nuestros argumentos más eficaces que el que Linux > puede reciclar equipos viejos. Parece que la obsolescencia programada > llegó al mundo Linux también. > > Saludos > ¿Lo tenían programado? ¿Tú crees que allá por 1995 Debian tomó la decisión de finalizar en 2018 o 2020 la compatibilidad con esos procesadores para forzar la compra de modelos nuevos? -- Manolo Díaz
Re: egrep en castellano vs egrep en inglés
El miércoles, 30 sep 2015 a las 15:45 UTC Camaleón escribió: > El Wed, 30 Sep 2015 17:13:13 +0200, Manolo Díaz escribió: > > > El miércoles, 30 sep 2015 a las 14:31 UTC Camaleón escribió: > > > >> Buscando en Google he visto que esta "característica" está documentada > >> en la versión de grep que tienes (2.21), vamos, que ni bug ni fantasmas > >> ni gaitas... misterio resuelto: > >> > >> http://savannah.gnu.org/forum/forum.php?forum_id=8152 > >> > >> If a file contains data improperly encoded for the current locale, > >> and this is discovered before any of the file's contents are output, > >> grep now treats the file as binary. > >> > > > > Extraño. Así que caracteres que son inválidos en utf8 pueden no serlo en > > C. Creía que el último era un subconjunto de cualquier otro. > > Lo que sucede es que el archivo "passwd" está codificado en "iso-8859" y > grep está usando utf-8 de ahí que lo interprete mal y en la nueva versión > te lo detecta como binario. Por lo que sé está codificado en ascii. > Al forzar el uso del locale C (le hubiera valido también > "LANG=es_ES.iso885915") lo interpreta como ascii y de hecho le podría dar > error igualmente dependiendo del tipo de caracteres que contuviera el > archivo. Volvemos a lo miso: dime un valor ascii que sean inválido en iso-8859-* o utf8. > Saludos, Saludos. -- Manolo Díaz
Re: egrep en castellano vs egrep en inglés
El miércoles, 30 sep 2015 a las 14:31 UTC Camaleón escribió: > Buscando en Google he visto que esta "característica" está documentada en > la versión de grep que tienes (2.21), vamos, que ni bug ni fantasmas ni > gaitas... misterio resuelto: > > http://savannah.gnu.org/forum/forum.php?forum_id=8152 > > If a file contains data improperly encoded for the current locale, > and this is discovered before any of the file's contents are output, > grep now treats the file as binary. > > Saludos, Extraño. Así que caracteres que son inválidos en utf8 pueden no serlo en C. Creía que el último era un subconjunto de cualquier otro. -- Manolo Díaz
Re: Mal funcionamiento ratón y teclado USB desde actialización a Debian 8
El miércoles, 30 sep 2015 a las 10:25 UTC alfon escribió: > Hola Fernando, > > No, no es inalámbrico. Como comento más bien parece un problema de software. > > Saludos. > > 2015-09-30 11:20 GMT+02:00 fernando sainz : > > El día 30 de septiembre de 2015, 9:13, alfon escribió: > >> Hola a todos! > >> > >> Veréis desde que he actualizado a Debian 8 me sucede una cosa muy > >> extraña con el teclado y el ratón USB de mi portátil: > >> > >> Algunas veces (no pasa siempre), cuando arranco las X, el ratón USB no > >> funciona y el teclado pierde grupos de pulsaciones de tecla de forma > >> aleatoria, por ejemplo. si escribo "ratón" en la terminal aparece sólo > >> "tón". > >> > >> Ya os digo que no pasa siempre, y cuando pasa lo resuelvo reiniciando. > >> > >> Por si os sirve de pista: > >> > >> > >> 1.- Si reinicio el equipo se soluciona el problema del ratón y teclado > >> (a veces no a la primera, pero sí tras reinicios sucesivos) > >> > >> 2.- Si desconecto y conecto el conector USB soluciona el problema del > >> ratón (pero no el problema del teclado) > >> > >> 3.- Si hago una serie de clics en el ratón vuelve a la vida durante > >> algún tiempo (sí, suena extraño) > >> > >> 4.- Sucede lo mismo que en el punto 3 si reinicio "udev" (el ratón > >> funciona durante algún tiempo, después de que muere de nuevo) > >> > >> No sé si os ha pasado a alguno. > >> > >> Estoy desesperado con el tema :_( > >> > >> Gracias de antemano. > >> > >> Saludos. > >> > > > > ¿ es inalámbrico ? > > > > Si lo es prueba con pilas nuevas en ambos, teclado y ratón. > > > > S2. No sé, es como si el sistema de ahorro de energía los durmiese cuando llevan un tiempo sin usar. Lo extraño es que también le ocurre al teclado. -- Manolo Díaz
Re: [OT] renombrado secuencial de archivos
El martes, 29 sep 2015 a las 13:57 UTC Jorge A. Secreto escribió: > Cat no se lleva bien con la sustitucion de la entrada. :-P > > $ cat `ls -v *.txt` > pepe > cat: opción inválida -- '.' > > $ cat -- `ls -v *.txt` > pepe > cat: 01: No existe el fichero o el directorio Cómo que no se lleva bien. Di mejor que usas nombres de ficheros con espacios o algo así. De ser esto investiga la variable IFS, o mejor, dales un nombre de fácil manejo. -- Manolo Díaz
Re: [OT] renombrado secuencial de archivos
El martes, 29 sep 2015 a las 12:59 UTC Manolo Díaz escribió: > La orden sort es capaz de realizar ordenación numérica (parámetro -n). > Eso más una tubería te soluciona el orden correcto para la > concatenación. Quita tubería y pon sustitución de orden. -- Manolo Díaz
Re: [OT] renombrado secuencial de archivos
El martes, 29 sep 2015 a las 12:45 UTC Jorge A. Secreto escribió: > Hola gente! > Disculpen que consulte por esta pavada, pero estuve leyendo el man de awk, > el de sed, el de bash, busqué en google 'numerar archivos linea comando > linux' y cosas por el estilo y nada me sacó de mi ignorancia :-( > Tengo algunos miles de archivos de texto que tengo que concatenar en orden. > Están numerados con el orden que debo respetar al comienzo del nombre, por > ej '1 xxx.txt' '2 xxx.txt' etc. > El problema se me presenta cuando los uno con 'cat -s *.txt > unidos.txt', > porque el orden que usa cat para leerlos es alfabético en vez del orden > natural numérico, como haría 'ls -v', es decir, ordena '100 ''10 ''1 ' en > vez de '1 ''10 ''100 ', que es lo que necesito. > Podría armar algún programa, en alto nivel, para hacerlo, pero me parece > exagerado, creo que se tiene que poder hacer desde la línea de comando. > Si álguien de la lista fuera tan amable como para desasnarme, habría subido > un peldañito más en su camino al cielo. > Gracias y, nuevamente, disculpen que moleste. La orden sort es capaz de realizar ordenación numérica (parámetro -n). Eso más una tubería te soluciona el orden correcto para la concatenación. -- Manolo Díaz
Re: egrep en castellano vs egrep en inglés
El martes, 29 sep 2015 a las 12:04 UTC Gonzalo Rivero escribió: > Holas, > es que gran parte de mi planta de usuarios se está por mudar a otro > edificio de otra sucursal, así que estoy armando un nuevo samba para > los que se quedan (se va la mayoría así que el samba actual se va con > ellos), y me encontré con algo rarísimo al revisar el archivo de > claves para saber sus nombres ((si ya se: poner ldap, pero eso es > hasta el año que viene, porque es un proyecto demasiado grande 1+ > usuarios entre todas las sedes)) de usuario y crearlos en el nuevo > server. > si lo ejecuto normalmente: > $ egrep -i "(FULANO|MENGANO).*SUTANO" passwd > Coincidencia en el fichero binario passwd > > entonces quise tener ese mensaje en inglés para ir a google a ver bien > que significa y como mejorar esa salida (p.e. que me devuelva la linea > correspondiente a ese usuario en el archivo de claves) y al ejecutar > tuve lo que quería: > $ LANG=C egrep -i "(FULANO|MENGANO).*SUTANO" passwd > fmsutano:*:1163:100:Fulano Sutano:/home/fmsutano:/usr/sbin/nologin > > ¿alguien sabe a que puede deberse el cambio de personalidad según el > idioma en que lo ejecute?. Para mas datos, el grep que tengo en mi > debian testing es: > $ egrep -V > grep (GNU grep) 2.21 > ... > > y, no viene al caso pero no faltará quien diga que se ve raro, el > archivo de claves con el que estoy trabajando es de freebsd, por eso > el formato ligeramente distinto al de linux > Parece relacionado con esto: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799956 Aunque el remitente no hace mención a que funciona correctamente con la localización C. Quizá sea una pista útil para el mantenedor. -- Manolo Díaz
Re: Configuración fstab luego de separar directorios de sistema en distintas particiones
El lunes, 28 sep 2015 a las 16:51 UTC Frederit Mogollon escribió: > Aquí el sticky bit, "permite evitar que un usuario pueda borrar > ficheros/directorios de otro usuario dentro de ese directorio, ya que > todos tienen permiso de escritura" (tomado desde > http://rm-rf.es/permisos-especiales-setuid-setgid-sticky-bit/). > > Es una forma de proteger a todos de todos? Sí, tal como se explica arriba. Si tienes un fichero con los permisos restringidos en un directorio modificable por todos, un tercero no podría leer ni modificar ese fichero, pero sí borrarlo. Puede parecer contrario a la intuición, pero al borrarlo en realidad estás modificando el directorio padre, para lo cual todos tienen permiso. Este es el tipo de situación que soluciona el "sticky bit". -- Manolo Díaz
Re: Problemas de memoria
El lunes, 28 sep 2015 a las 14:13 UTC José Miguel (sio2) escribió: > Eso sí, insisto en que por mucho oom-killer, cuando a mí se me produjo > la situación, no podía usar el servicio ssh, porque aunque éste estaba > activo, no era capaz de abrir sesión. Si he entendido bien lo básico sobre el tema, oom-killer solo funciona en el modo overcommit = 0. Saludos. -- Manolo Díaz
Re: Problemas de memoria
El domingo, 27 sep 2015 a las 21:05 UTC Santiago Vila escribió: > On Sun, Sep 27, 2015 at 07:32:26PM +0200, Manolo Díaz wrote: > > > No es muy elegante, pero no creo que los desarrolladores de Linux se > > hayan levantado un día aburridos y decidieran programar una aberración. > > Parece que las soluciones obvias al límite de la memoria son (aparte de > > aumentarla) o eliminar procesos, o impedir que se lancen nuevos. > > Y te ofrecen que elijas entre dos soluciones nada elegantes. > > La verdad siempre es más elegante que la mentira. > > Los procesos piden memoria y el núcleo les dice, "toma, aquí la tienes", > pero en realidad es mentira, si todos los procesos usaran la memoria > que han pedido y en teoría les ha sido concedida resulta que no hay > para todos. > > "Ay, no, que te he dado una memoria que en realidad no tengo, ahora > por pretender usar la memoria que te he dado y para enmendar mi error, > vas a morir". > > No sé qué harán los desarrolladores de Linux cuando estén aburridos, > pero esto del overcommit, y después de leer todo lo que he podido > sobre el tema, me parece una chapucilla. > Pero es que no hay solución ideal. Al ajustar overcommit respondes una pregunta sobre una situación límite: qué hago si me quedo sin memoria. Porque si ponerse a aniquilar procesos para desalojar memoria es un disparate, lo que le ha sucedido a José Miguel tampoco se queda atrás, y dejar que las aplicaciones en curso vayan fallando estrepitosamente no es la alegría de la huerta (¿vm.overcommit_memory = 1?). -- Manolo Díaz
Re: Problemas de dependencia(actualización emacs24 debian testingI
El domingo, 27 sep 2015 a las 17:46 UTC Camaleón escribió: > > En Debian sid hay más errores de dependencias y hacen que el sistema se > > rompa en cualquier momento; se supone que debian testing tiene un poco > > más de estabilidad que sid. > > Testing es una sid con 1 mes de retraso, vamos, que se puede romper de la > misma manera, aunque es verdad que eso sucede menos. No. En testing no debe haber problemas de dependencia. Las veces que ocurre son contadas y se considera fuera de lo normal, al contrario que en unstable. https://www.debian.org/doc/manuals/debian-faq/ch-ftparchives#s-testing -- Manolo Díaz
Re: Problemas de memoria
El domingo, 27 sep 2015 a las 14:00 UTC Santiago Vila escribió: > On Sun, Sep 27, 2015 at 01:46:14PM +0200, José Miguel (sio2) wrote: > > Parece que hay memoria libre, pero si por: > > > > vm.overcommit_memory = 2 > > > > no se puede ocupar más del 50%RAM+SWAP (6GB de memoria) con lo cual es > > plausible pensar que se llegó a ese límite cuando no podía acceder al > > servidor. > > Esto es lo que te decía antes. Si no dices nada más entonces la memoria > que puede asignar es swap + 50% de la RAM. > > Si tienes 2GB de swap y 8GB de RAM, te estás limitando a usar 6 GB de > memoria en total. Pero tienes 8 GB así que estás desaprovechando > completamente 2 GB de RAM de la forma más escandalosa. > > Si de verdad no quieres que pida más de 8 Gigas, sube el SWAP a 4 Gigas > manteniendo la regla de SWAP + 50% de RAM. Pero incluso así estarías > desaprovechando la memoria disponible. Si las aplicaciones "piden" el > doble de lo que realmente necesitan y decides darles 8 Gigas como > máximo, entonces solamente llegarás a usar 4 GB de verdad. > > Por supuesto que es una exageración, pero es para que te hagas una idea. > > Otra posibilidad es dejarle que use *toda* la memoria disponible: > > vm.overcommit_memory = 2 > vm.overcommit_ratio = 100 > > > @ManoloDiaz > > > Sugiero que investigues el ajuste OOM score, se hace por procesos y > > > creo que systemd lo gestiona sin dificultad. Así podrías establecer > > > una jerarquía para ver cuáles son los últimos en ser aniquilados por > > > el núcleo cuando empieza a faltar memoria. > > > > Pues no tenía ni idea de esto. He ido a mirar y he visto que el SSH > > tiene, así sin tocarlo, el oom_score_adj a -1000. O sea, que el > > oom-killer no se lo cargará, cosa que me interesa. > > No te interesa que se cargue *ningún* proceso. > > Esto del OOM killer en realidad es una aberración. Es como si unas > líneas aéreas deciden que cuando un avión está bajo de combustible > se elige un pasajero al azar y le dan al botón de "eject" para > ese pasajero. Al azar no. Los mantenedores de sshd parecen estar lo bastante lúcidos como para hacer que esté disponible casi en cualquier contingencia. En un caso como este en el que el servidor está en "El País de Muy, Muy Lejano" eso es de lo más conveniente. > Mejor lee el original de Andries Brouwer: > > https://lwn.net/Articles/104185/ > > No pierdas el tiempo haciendo "ajustes" del OOM killer. Es como si te > andaras rompiendo la cabeza afinando el algoritmo por el que se decide > qué pasajero expulsas del avión... No es muy elegante, pero no creo que los desarrolladores de Linux se hayan levantado un día aburridos y decidieran programar una aberración. Parece que las soluciones obvias al límite de la memoria son (aparte de aumentarla) o eliminar procesos, o impedir que se lancen nuevos. Y te ofrecen que elijas entre dos soluciones nada elegantes. -- Manolo Díaz
Re: Problemas de memoria
El sábado, 26 sep 2015 a las 14:59 UTC José Miguel (sio2) escribió: > El Sat, 26 de Sep de 2015, a las 02:20:00PM +, Camaleón dijo: > > > Lo primero sería ejecutar "free" (para ver qué cantidad de RAM hay en uso/ > > disponible) y "top" (para ver qué servicios están consumiendo más RAM). > > Sí, eso ya lo he dejado dicho. En vez de "top" he sugerido "ps" para > poder volcar a un disco. El problema es que no haya memoria para abrir > una sesión bash. :( > > >> Por cierto con eso de 2719744 bytes asignados, ¿a qué se refiere? > >> ¿Asignados a quién? Porque no puede ser la memoria total, que es 8 GB. > > > > Al cerrarte la sesión SSH entiendo que se referirá a eso, que no puede > > ubicar la memoria necesaria para abrir una sesión de bash, asignar una > > terminal, etc. > > No, si yo también. Lo que no sé es qué significa exactamente ese número > 2719744 (~2.6 GiB). ~2.6 MiB > Un saludo y gracias. > Sugiero que investigues el ajuste OOM score, se hace por procesos y creo que systemd lo gestiona sin dificultad. Así podrías establecer una jerarquía para ver cuáles son los últimos en ser aniquilados por el núcleo cuando empieza a faltar memoria. Saludos. -- Manolo Díaz
Re: sudo aptitude se bloquea
El viernes, 25 sep 2015 a las 15:38 UTC
AlexLikeRock escribió:
> 1.-yo miro que estas corriendo como usuario normal y eso esta mal
>
> $./actualiza.sh
> ^^
> tienes que correrlo como root
El objeto de sudo dentro del script es _precisamente_ evitar la
necesidad de ejecutarlo como root. De hecho, como señala Adrià, el
primer aptitude se ejecuta mientras que el segundo no. Y ambos
necesitan privilegios de administrador.
Yo intentaría [1]:
sudo { aptitude update && aptitude full-upgrade -y; }
Bueno, no. La verdad es que yo no intentaría 'full-upgrade -y' ni bajo
los efectos de mi peor resaca. Pero esa es otra historia.
[1] man sh
--
Manolo Díaz
Re: [OT] Placa de video Nvidia Gforce no reconocida
El viernes, 25 sep 2015 a las 13:00 UTC Sergio Bessopeanetto escribió: > Estimados/as: [...] > La placa madre es una Asrock 775i65gv la cual dispone de 3 slots PCI y > uno AGP. Pues entonces compré usada una placa Gforce 6200 Xfx AGP 8X > DDR2 de 256 Mb. La instalé y sencillamente no la reconoce. En el manual > de la mother da una lista de posibles placas de video compatibles. La > que compré no figura pero pensé que se trataría porque el manual está > desactualizado ya que esta placa es más nueva que la mother. [...] No aparece ni en un listado más actualizado: http://www.asrock.com/mb/Intel/775i65GV/?cat=VGA Ahí aparecen, creo, tarjetas más modernas pero no lista la que mencionas. -- Manolo Díaz
Re: [OT] Peticiones en cluster apache
El viernes, 25 sep 2015 a las 11:55 UTC Maykel Franco escribió: > El día 25 de septiembre de 2015, 13:36, Manolo Díaz > escribió: > > El viernes, 25 sep 2015 a las 10:29 UTC > > Maykel Franco escribió: > > > > > > [...] > > > >> Se os ocurre algo?? Podría usar esta orden pero solo sirve desde que > >> se ejecuta y para las ultimas x lineas...Lo veo como ñapa: > >> > >> watch -n 10 "tail -n 3 ssl_access.log | cut -f1 -d' ' | uniq -c | > >> sort -r | head -n 20" > >> > >> > >> Gracias de antemano. > >> > > > > El límite de 3 (o el que sea) lo puedes evitar fácilmente: > > > > tail -f -n +1 ssl_access.log | cut -f1 -d' ' | uniq -c | sort -r | head -n > > 20 > > > > Hace lo mismo sin ese límite y sin necesidad de watch: la salida se > > actualiza continuamente. > > > > Saludos. > > -- > > Manolo Díaz > > > > > Ummm, no me aparece nada...Se queda ahí sin más... > Sí, fallo mío. Tanto uniq como sort tienen que leer el contenido completo antes de hacer su trabajo. -- Manolo Díaz
Re: [OT] Peticiones en cluster apache
El viernes, 25 sep 2015 a las 10:29 UTC Maykel Franco escribió: [...] > Se os ocurre algo?? Podría usar esta orden pero solo sirve desde que > se ejecuta y para las ultimas x lineas...Lo veo como ñapa: > > watch -n 10 "tail -n 3 ssl_access.log | cut -f1 -d' ' | uniq -c | > sort -r | head -n 20" > > > Gracias de antemano. > El límite de 3 (o el que sea) lo puedes evitar fácilmente: tail -f -n +1 ssl_access.log | cut -f1 -d' ' | uniq -c | sort -r | head -n 20 Hace lo mismo sin ese límite y sin necesidad de watch: la salida se actualiza continuamente. Saludos. -- Manolo Díaz
Re: [OT] Opinión sobre discos duros y mecanismos de respaldo.
El jueves, 24 sep 2015 a las 17:12 UTC Juan Lavieri escribió: > *Minimum Hardware Requirements:* > > These specifications will suffice to get a small FreeNAS install running > reliably with moderate performance for a few users. > >- Multicore 64-bit* processor (Intel strongly recommended) >- 8GB* Boot Drive (USB Flash Drive suffices) >- 8GB* RAM >- At least 1 direct attached disk (Hardware RAID *strongly* discouraged) Me pregunto por qué. En teoría el resto del sistema lo ve como un solo disco. ¿Falta de controlador? >- One physical network port -- Manolo Díaz
Re: [OT] Opinión sobre discos duros y mecanismos de respaldo.
El miércoles, 23 sep 2015 a las 03:39 UTC Edwin De La Cruz escribió: > RAID o NO RAID? > Sirve de algo tener un disco espejo de respaldo si los mismo archivos > corruptos o datos X danados son copiados en el? > Sirve de algo si los archivos del sistema operativo se corrompen y asi > son respaldados quedando igualmente sin poder arrancar? El propósito de un RAID no es el de copia de seguridad, sino evitar la caída de servicio cuando fallan simultáneamente un número de discos, dependiendo del tipo y configuración del RAID. -- Manolo Díaz
Re: darse de baja
El martes, 22 sep 2015 a las 23:47 UTC Antonio Sanjuanes escribió: > Estimados señores, > > agradecería que me indicaran como me doy de baja de la lista > Escribe un correo a la dirección debian-user-spanish-requ...@lists.debian.org que lleve por asunto la palabra unsubscribe. Recibirás otro correo que te pida confirmación. Responder sin modificar el asunto será suficiente. Saludos. -- Manolo Díaz
Re: Reinicios aleatorios
El lunes, 21 sep 2015 a las 11:24 UTC Hernan Javier Lopez escribió: > El lun., 21 sept. 2015 a las 4:07, Josu Lazkano () > escribió: > > > Buenos dias de nuevo, > > > > He apagado el servidor para ver el modelo de ventilador que tengo: ARCTIC > > F8 > > > > Tengo hueco para poner uno de 12cm, asi que quitare el de 8 y lo > > pondre en la tapa. Alguna recomendacion sobre un ventilidor de 12cm? > > > > He aprovechado para entrar a la BIOS y sacar una foto a las > > temeperaturas: http://i61.tinypic.com/2n6dk02.jpg > > > > Puedo cambiar algo en la BIOS? > > > > Muchas gracias por vuestras sugerencias. > > > > Un saludo. > > > > -- > > Josu Lazkano > > > > > Solo para saber, esta limpia? O sea, antes de ponerle ventiladores revisa > la cantidad de polvo y pelusa que podes tener acumulado. Sobre todo en los > disipadores, y ranuras de chips de memoria. Eso te puede hacer una > diferencia de mas de 20° > Saludos Parece que es de 2007. Yo además desmontaría el disipador del procesador, le limpiaría la pasta térmica entre ambos y le aplicaría nueva, si no lo has hecho recientemente. -- Manolo Díaz
Re: aptitude perdido
El domingo, 20 sep 2015 a las 23:30 UTC Ricardo Delgado escribió: > Buenas, el punto es el siguiente en mi testing semanalmente hago un > aptitude full-upgrade -y > > luego de ello, note que se habia "desaparecido" aptitude, instale en > forma manual nuevamente pero me pidio otras dependencias libcwidget3v5 > libsigc++-2.0-0v5, > >ahora tengo nuevamente aptitude, espero que en mi proxima > actualizacion no me de este problemilla > > slds Pues entonces no ejecutes 'aptitude full-upgrade -y'. Parece que, en ocasiones, la transición es más fluida si algunos paquetes abandonan temporalmente testing. Vaya, que perfectamente podría volver a ocurrirte con otro. Saludos. -- Manolo Díaz
Re: Reinicios aleatorios
El miércoles, 16 sep 2015 a las 13:08 UTC Josu Lazkano escribió: > Buenas, > > Gracias a todos por responder. > > He estado monitoreando la temperatura y no sube demasiado: > > http://i61.tinypic.com/avrgqe.png Coincido con Cristian. Esa gráfica anterior marca 87 ºC de máxima para el núcleo 2, superando la máxima que recomienda el fabricante (80 ºC) y no muy lejos del valor de la temperatura crítica (100 ºC) según sensors. ¿Tienes datos inmediatamente anteriores al reinicio? > http://i61.tinypic.com/29pswsk.png > http://i58.tinypic.com/20u3k35.png > http://i60.tinypic.com/2lid37k.png > > Ayer se me reinicio otra vez a las 20:45, en la grafica no se ve gran cosa. > > Ya he creado la carpeta "journal", a ver si estos dias veo algo mas. > > Saludos. > -- Manolo Díaz
Re: apt-update error: la suma hash difiere
El martes, 15 sep 2015 a las 15:58 UTC Billy Yeffry Fernández Rodríguez escribió: > Saludos, > > Tengo el siguiente inconveniente para actualizar a debian 8.2: > > Tengo la desventaja de no poseer una conexion a internet a mi hogar, > asi que dispongo de un repository offline mediante apt-mirror, al cual > voy actualizando segun cada actualizacion de jessie. En la ultima > actualizacion, apt-get update me retorna el siguiente error: > > sudo apt-get update > Des:1 file: jessie InRelease [134 kB] > W: Fallo al obtener > file:/home/billy/Documentos/debian_jessie/jessie_repo/mirror/ftp.us.debian.org/debian/dists/jessie/main/binary-i386/Packages > La suma hash difiere > > W: Fallo al obtener > file:/home/billy/Documentos/debian_jessie/jessie_repo/mirror/ftp.us.debian.org/debian/dists/jessie/main/i18n/Translation-en > La suma hash difiere > > E: No se han podido descargar algunos archivos de índice, se han > omitido, o se han utilizado unos antiguos en su lugar. > > - > > EL mirror que uso es: > > deb http://ftp.us.debian.org/debian jessie main contrib non-free > > que me sugieren? > Intentar de nuevo la actualización de tu repositorio local con apt-mirror. Supongo que apt-mirror te avisa en caso de actualización fallida. -- Manolo Díaz
Re: Reinicios aleatorios
El lunes, 14 sep 2015 a las 06:12 UTC Josu Lazkano escribió: > Hola a todos, > > Tengo un servidor con Jessie que de vez en cuando (cada 2 dias aprox.) > se reinicia. > > ¿Como puedo saber porque es? Puedo guardar los logs del sistema y ver > despues del reinicio? > > Gracias por todo. > > Saludos. > Si no hay registro puede ser problema físico, como ya te han dicho, pero también puede ser por un error irrecuperable del núcleo si está configurado con esa característica [1]. Por lo que veo Debian no la activa. Si no usas un núcleo personalizado puedes ignorar este motivo. Saludos. [1] CONFIG_PANIC_ON_OOPS=y -- Manolo Díaz
Re: OT: comparar fechas de ficheros
El viernes, 11 sep 2015 a las 09:44 UTC Manolo Díaz escribió: > Ejemplo: encontrar ficheros más recientes que 2014-06-17 a las > 23:01:11 > > touch -d '2014-06-17 23:01:11' /tmp/fichero_de_referencia > find [directorio] -newer /tmp/fichero_de_referencia Curioseando sobre el asunto de la necesidad de crear un fichero con el cual comparar, he visto que ha pasado a la historia. Viene documentado en la página man de find (-newerXY reference), pero no en la traducida al español, que está un poco obsoleta. -- Manolo Díaz
Re: OT: comparar fechas de ficheros
El viernes, 11 sep 2015 a las 09:20 UTC Juan Guil escribió: > Hola > > me gustaria hacer un script para controlar la antigüedad de unos ficheros. > > Entonces, lo que me gustaria es, que este script saque la fecha de > cada fichero y la compare, si esta, tiene mas de una semana, pues me > lo diga o lo detecte. > > Recuerdo que, hay una forma de sacar una fecha comparada con una fecha > en el pasado, y en funcion a este numero podias hacer los calculos. > > > ¿Alguien me podia dar una pista?, Para lo que dices necesitar ya te ha respondido OddieX. Para lo último se puede usar el truco de crear un fichero con la fecha y hora que necesites y después usar find. Ejemplo: encontrar ficheros más recientes que 2014-06-17 a las 23:01:11 touch -d '2014-06-17 23:01:11' /tmp/fichero_de_referencia find [directorio] -newer /tmp/fichero_de_referencia -- Manolo Díaz
Re: squi3 e iptables
El jueves, 10 sep 2015 a las 17:21 UTC l...@ida.cu escribió: > Buenas a todos he tenido que migrar y no he dado mucho pie con bola con > el squid3 en comparación con el 2.7 que tenía > > Alguien puede enviarme para guiarme una conf de squid3 para q los > usuarios autentiquen con la básica: > > #Modulo de autenticacion > authenticate_ip_ttl 5 minutes > auth_param basic children 5 > auth_param basic realm Servidor de Navegacion > auth_param basic credentialsttl 2 hours > auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/privados > > En el squid3 no logro hacerlo me rechaza las conexiones > > > > Me pueden dar una mano, para más tengo que montar firewall con iptables > aunque nunca he trabajado con este he leído pero cero experiencia pero > eso es lo que haré si tiene algo para guiarme pues tanto mejor > > saludos y agradezco toda ayuda ¿Y no te ayuda la documentación incluida en el paquete? Veo que están disponibles las siguientes páginas man relacionadas: squid: /usr/share/man/man8/basic_db_auth.8.gz squid: /usr/share/man/man8/basic_getpwnam_auth.8.gz squid: /usr/share/man/man8/basic_ldap_auth.8.gz squid: /usr/share/man/man8/basic_ncsa_auth.8.gz squid: /usr/share/man/man8/basic_pam_auth.8.gz squid: /usr/share/man/man8/basic_radius_auth.8.gz squid: /usr/share/man/man8/basic_sasl_auth.8.gz Sin tener ni idea pero sabiendo que antes de la actualización funcionaba, empezaría por comprobar los ajustes personalizados: veo un /etc/squid/privados por ahí... -- Manolo Díaz
Re: Openssl
El miércoles, 9 sep 2015 a las 21:51 UTC Carlos Zuniga escribió: > 2015-09-09 11:53 GMT-05:00 Manolo Díaz : > > El miércoles, 9 sep 2015 a las 16:30 UTC > > Gonzalo Rivero escribió: > > > >> El mar, 08-09-2015 a las 23:07 -0430, Edward Villarroel (EDD) escribió: > >> > buenas noches > >> > > >> > > >> > tengo una duda con open ssl > >> > > >> > > >> > si asi se Encriptar y Desencriptar: > >> > > >> > OpenSSL> rsautl -pubin -encrypt -in entrada.txt -out salidaRsa.txt > >> > -inkey publica1.key > >> > OpenSSL> rsautl -decrypt -in salidaRsa.txt -out salidaRsa2.txt -inkey > >> > privada1.key > >> > > >> > pero esto es llaveencripto publica > Desencripto privada > >> > > >> > ===>>>>>>>>>>>> > >> > <<<<<<= > >> > > >> > > >> > como se hace para encripto privada > Desencripto publica > >> > ?? > >> > > >> > > >> juraría que la idea de la clave pública/privada es justo lo contrario: > >> bob le quiere mandar a alice un mensaje que quiere que solo alice lo > >> vea. Pero no quiere decirle a alice su clave privada, entonces lo cifra > >> con la clave pública de alice, y ella lo descifra con su propia clave > >> privada (también no se supone que bob conozca la clave privada de > >> alice) > >> > >> lo mismo puedo estar equivocado, que alguien me corrija > > > > Tampoco le veo sentido a cifrar con la privada para que se pueda > > descifrar con la pública, que se supone ampliamente difundida. Sería un > > secreto a voces. > > > > Usas doble cifrado: Bob cifra con su llave privada y con la llave > pública de Alice. Alice descifra con su llave privada y con la llave > pública de Bob. Así se aseguran que el mensaje realmente llega de Bob, > solo lo pueda leer Alice y nadie curiosee en el camino. Cierto. No había caído en garantizar el remitente, solo en el secreto del mensaje. > Si cifras solo un hash con tu llave privada como dice José Miguel > sería firmar el mensaje. Que es bastante util, por ejemplo si generas > un ejecutable binario puedes firmarlo para que los demás se aseguren > que estan descargando tu binario y no algún virus impostor. > -- Manolo Díaz
Re: Openssl
El miércoles, 9 sep 2015 a las 16:30 UTC Gonzalo Rivero escribió: > El mar, 08-09-2015 a las 23:07 -0430, Edward Villarroel (EDD) escribió: > > buenas noches > > > > > > tengo una duda con open ssl > > > > > > si asi se Encriptar y Desencriptar: > > > > OpenSSL> rsautl -pubin -encrypt -in entrada.txt -out salidaRsa.txt > > -inkey publica1.key > > OpenSSL> rsautl -decrypt -in salidaRsa.txt -out salidaRsa2.txt -inkey > > privada1.key > > > > pero esto es llaveencripto publica > Desencripto privada > > > > ===>>>>>>>>>>>> > > <<<<<<= > > > > > > como se hace para encripto privada > Desencripto publica > > ?? > > > > > juraría que la idea de la clave pública/privada es justo lo contrario: > bob le quiere mandar a alice un mensaje que quiere que solo alice lo > vea. Pero no quiere decirle a alice su clave privada, entonces lo cifra > con la clave pública de alice, y ella lo descifra con su propia clave > privada (también no se supone que bob conozca la clave privada de > alice) > > lo mismo puedo estar equivocado, que alguien me corrija Tampoco le veo sentido a cifrar con la privada para que se pueda descifrar con la pública, que se supone ampliamente difundida. Sería un secreto a voces. -- Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El martes, 8 sep 2015 a las 15:24 UTC Ismael L. Donis Garcia escribió: > >- Original Message - > >From: "Santiago Vila" > >To: > >Sent: Tuesday, September 08, 2015 8:25 AM > >Subject: Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”? > > > > >On Tue, Sep 08, 2015 at 01:37:42PM +0200, Ala de Dragón wrote: > >> ¿Yo como usuario puedo desinstalar completamente todo lo relacionado > >> con systemd y volver a systemV? > > > >Se ha explicado ya muchas veces. En Debian 8 sysvinit todavía está > >soportado. Hay un paquete llamado systemd-shim que emula funciones > >de systemd sin ser systemd. > > > >P.S. No seas tan radical. No quieras desinstalar "todo lo relacionado" > >con systemd. Tendrías que quitar udev (que está en el mismo código > >fuente que system) y no creo que te convenga usar Debian sin udev. > > Si fueras un usuario avanzado podrías probar instalando vdev y eliminar udev > > Saludos > > | ISMAEL | > Y tan avanzado. Como que tendrías que crearte tú el paquete correspondiente. -- Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El martes, 8 sep 2015 a las 17:15 UTC Mario A. Guerra escribió: > El 08/09/15 a las 11:21, Camaleón escribió: > > El Tue, 08 Sep 2015 13:37:42 +0200, Ala de Dragón escribió: > > > > (...) > > > >> ¿Yo como usuario puedo desinstalar completamente todo lo relacionado con > >> systemd y volver a systemV? > > > > Eso, amigo, no es posible desde ya en ninguna distribución linuxera > > mayoritaria salvo que te guste (muy mucho) compilar :-) > > > > Saludos, > > > > Humildemente pienso que no es tan así, en el siguiente link se muestra > un listado de todas las distribuciones GNU/Linux (y otras que no) que no > tienen systemd, y no hay nada para compilar, la mayoría son distros > listas para usar: > > http://without-systemd.org/wiki/index.php/Main_Page Que aparezca Devuan, que no es aún un proyecto apto para sistemas en producción, me hace desconfiar del listado. > En el caso de Debian 8, se puede desinstalar prácticamente todo lo > referido a systemd, a costa de perder ciertas funcionalidades. Estoy de acuerdo. > En mi caso tengo 2 máquinas configuradas de esta forma y me estoy > arreglando bien. > > Saludos, Mario Saludos. -- Manolo Díaz
Re: no puedo copiar a memoria usb
El martes, 8 sep 2015 a las 11:53 UTC l...@ida.cu escribió: > Buenos días > > Tengo instalado debian jessie amd64, cuando intento copiar un fichero > para una memoria usb me sale lo siguiente > > "Sistema de fichero de solo lectura (30). > > > Le he cambiado con chmod 777 al fichero y nada no me lo deja copiar. De nada sirve eso cuando es el sistema de ficheros que lo contiene el que está montado en modo de solo lectura. > Alguna idea no se si tiene que ver con el fstab.??? A eso te podríamos responder mejor si mostrases su contenido, al menos las líneas relevantes. Aunque lo habitual es que no contenga las unidades extraíbles, hace tiempo suelen gestionarse con udisks. > Gracias a todos > > Saludos. -- Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El martes, 8 sep 2015 a las 05:36 UTC
Alejandro Alcántar escribió:
> 2.- el echo q Los LOGs Sean BINARIOS atenta contra una de Las leyes del
> software libre. Ya que es ilegible .
Vamos a ver, el Gimp que ejecuto (por poner un ejemplo) es binario y me
guarda las imágenes creadas también en binario. Según ese criterio no es
software libre, en contra de lo aceptado por todos.
> {A} esto Nos alerta a un futuro cercano donde systemd y Sus BIBLIOTECAS
> tambien seran binarios
A ver cómo se ejecutan si no. Aunque tal vez quieras decir que solo se
distribuirán los binarios y el código fuente será inaccesible. Bola de
cristal aparte, de ser así es de esperar que se ramifique el proyecto
partiendo de una versión anterior libre.
El resto de los argumentos creo que ya se han discutido en este mismo
hilo.
Saludos.
--
Manolo Díaz
Re: DNIe con plugins de Java (was: a vueltas con dnie una curiosidad)
El lunes, 7 sep 2015 a las 15:27 UTC Alberto Luaces escribió: > Según recuerdo, a mí me funciona bien con páginas que hacen uso del DNIe > como un certificado más (al estilo de la FNMT). > > Sin embargo, no he tenido suerte con sitios como las páginas de los > bancos, en las que usan plugins de Java. ¿Alguien ha tenido éxito con > éstas? Ni idea, pero sí que he tenido problemas con la aplicación PADRE, la de la declaración de la renta, en la que se puede autenticar mediante certificado digital (precisamente del FNMT); me fue del todo imposible. Así que posiblemente el problema esté en la aplicación Java. -- Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El domingo, 6 sep 2015 a las 14:45 UTC Camaleón escribió: > >> > Si hablas de _sistemas de inicio en uso_ son estas las que deben > >> > usarse _a partir de Jessie_: > >> > > >> > systemd-sysv → votos: 34 % > >> > sysvinit-core → votos: 2 % > >> > upstart → testimonial, ni se acerca al 1 % > >> > >> Vale, ahora cambias los paquetes. Te has dado cuenta de que Jessie > >> tiene un paquete marcado como "esencial" que es "init" y que tiene que > >> instalar alguno de esos 3. > > > > ¿Por qué crees que he puesto esos tres y solo esos tres? > > Porque los otros paquetes ofrecían unos porcentajes que no eran > favorables a systemd. Te recuerdo que Wheezy también permite instalar > systemd. No. ¿Recuerdas que asigné el 66 % restante a sysv? En todo caso habré sido injusto con systemd ¿Y que he repetido constantemente la coletilla "a partir de Jessie"? Es porque hay un antes y un después, y popcon los mezcla. Después: cada uno de esos tres paquetes señala unívocamente el sistema de inicio. sysvinit no indica cuál usas, solo que actualizas desde Wheezy y no lo has suprimido. Antes: No se puede deducir a partir de los paquetes instalado. Si solo tenías sysvinit queda claro. Pero los datos no te dan información de cuántos instalan sysvinit pero no systemd, cosa posible en Wheezy. Y si tienes los dos es "vote" el campo que decide cuál usas regularmente. Contabilizar las instalaciones de sysvinit es un manera errónea de proceder por los motivos explicados. Saludos. -- Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El domingo, 6 sep 2015 a las 13:29 UTC
Camaleón escribió:
> El Sat, 05 Sep 2015 19:47:46 +0200, Manolo Díaz escribió:
>
> > El sábado, 5 sep 2015 a las 16:12 UTC Camaleón escribió:
>
> (...)
>
> >> Y como veo que sigues empecinado en los datos del Popcon, sysvinit gana
> >> por goleada a systemd, así que siguiendo tu argumento éste ("sysvinit")
> >> es el que se debería potenciar.
> >>
> >> Systemd → instalaciones (43,16%), votos (38,09%)
> >> Sysvinit → instalaciones (70,68%), votos (55,48%)
> >
> > No te has enterado de lo que quiero decir.
>
> O quizá es es que no te gustan los datos que tú mismo has enviado.
No los envíos porque me gusten, lo envíos porque son datos y no
suposiciones, ni deseos, ni románticas ensoñaciones.
>
> > Si hablas de _sistemas de inicio en uso_ son estas las que deben usarse
> > _a partir de Jessie_:
> >
> > systemd-sysv → votos: 34 %
> > sysvinit-core → votos: 2 %
> > upstart → testimonial, ni se acerca al 1 %
>
> Vale, ahora cambias los paquetes. Te has dado cuenta de que Jessie tiene
> un paquete marcado como "esencial" que es "init" y que tiene que instalar
> alguno de esos 3.
¿Por qué crees que he puesto esos tres y solo esos tres? init solo se
encarga de que el sistema pueda arrancar obligándote a a instalar uno y
solo uno de ellos. init, de por sí, no te indica nada sobre cuál es y
por eso no lo menciono. Los datos que elijo son significativos. No
sobra ni falta nadie para el propósito que nos ocupa.
> ¿Y qué significa eso? Pues nada, bueno sí, dos dos cosas: 1/ que las
> instalaciones nuevas de jessie instalan systemd+systemd-sysv (opción
> predeterminada) y 2/que los equipos que se actualizan desde versiones
> anteriores mantienen el paquete de compatibilidad con systemv (de ahí el
> alto porcentaje tanto de instalaciones como voto del paquete sysvinit).
>
> Es decir, que poca gente con Jessie se atreve por apostar únicamente por
> systemd.
Ese es un error tuyo persistente. sysvinit (sigo recalcando que a
partir de Jessie) no tiene el valor que tú le asignas.
De la descripción de dicho paquete:
If your system successfully boots with systemd or if you have chosen
to stick with sysvinit-core, this package can be removed safely.
Es decir, una vez actualizado a Jessie y efectuado correctamente el
primer arranque posterior, ese paquete está de más, aunque no estorba.
Lo puedes suprimir tranquilamente. Lo podemos ignorar.
> > ¿Significa eso que sysv sea menos usado que systemd? No, porque antes de
> > Jessie, sysvinit era quien contenía el sistema de arranque.
>
> No lo sabemos, Popcon no te dice (porque no puede hacerlo) si alguien con
> systemd instalado sigue usando el sistema antiguo para gestionar los
> servicios (es decir, que usa "service [] start" en lugar de "systemctl
> []...).
>
> > *Sospecho* que las cifras actuales de uso como sistema de arranque deben
> > andar por 66 % (sysv) y 34 % (systemd), con un matiz que añadir: No se
> > puede deducir la simpatía del usuario en ningún caso.
>
> Menos mal :-)
>
> > En el primero porque la práctica totalidad es de instalación
> > obligatoria (pre-Jessie), y en el segundo por lo que podríamos llamar
> > "efecto pereza" por ser el predeterminado. Popcon no puede usarse para
> > eso. Sí se puede (y era mi intención cuando lo mencioné) para señalar
> > que systemd no tiene un uso marginal [1], como es el caso de upstart.
>
> Yo no sospecho nada porque como llevo diciendo desde el principio, Popcon
> no ofrece datos que sirvan para poder sacar conclusiones de ningún tipo.
> Sería como decir que ext4 es el sistema de archivos por el que votan los
> debinitas simplemente porque es el más usado. Normal, es el
> predeterminado por lo que de 10 instalaciones 8 lo llevarán como sistema
> de archivos para la raíz y no hace falta tirar del Popcon para saber eso.
>
> En cuanto a los paquetes minoritarios (como "upstart") pues tampoco dice
> mucho porque nunca ha gozado de un estatus como ha tenido sysvinit ni
> como tiene ahora systemd, es decir, nunca lo han potenciado por lo que
> los usuarios no lo han probado y sólo los que vengan de Ubuntu sabrán
> cómo funciona, lo que permite y si merece la pena instalarlo.
>
> Saludos,
>
Sí se pueden sacar conclusiones. "Vote" tiene un significado muy claro
en popcon, donde está definido sin ambigüedades. Otra cosa es que tú
deseas una especie cuestionario de satisfacción del usuario. Una
petición muy razonable, pero no fue diseñado para eso.
Vuelvo a los datos: ambos sistema son claramente dominantes donde son
los predeterminados; la inmensa mayoría de usuarios aceptan lo que
Debian decide al respecto.
Saludos.
--
Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El sábado, 5 sep 2015 a las 16:12 UTC
Camaleón escribió:
> El Sat, 05 Sep 2015 17:40:30 +0200, Manolo Díaz escribió:
>
> > El sábado, 5 sep 2015 a las 15:20 UTC Camaleón escribió:
>
> (...)
>
> >> > Pero para sysvinit y systemd-sysv (Debian testing actualizada,
> >> > sin privilegios de administrador)...
> >>
> >> (...)
> >>
> >> No es un buen ejemplo: sólo faltaría que systemd no fuera
> >> compatible con sysvinit, su inmediato antecesor, vamos, le
> >> hubieran caído chuzos de punta a las distribuciones linuxeras que
> >> se hubieran pasado a systemd sin tener retrocompatibilidad con el
> >> sistema anterior :-)
> >
> > Yo creo que sí, porque en todo momento se ha hablado de la cifra de
> > instalación de sysvinit y systemd cuando resulta que (desde Jessie
> > hasta el momento) los sistemas de inicio son sysvinit-core,
> > systemd-sysv y upstart. Y esos tres sí que son incompatibles. De
> > hecho tienes que elegir uno y solo uno.
>
> Pues yo juraría que estabas hablando (o querías hablar¹) de la cifra
> de "votos" no de "instalaciones", pero en fin...
>
> Y como veo que sigues empecinado en los datos del Popcon, sysvinit
> gana por goleada a systemd, así que siguiendo tu argumento éste
> ("sysvinit") es el que se debería potenciar.
>
> Systemd → instalaciones (43,16%), votos (38,09%)
> Sysvinit → instalaciones (70,68%), votos (55,48%)
No te has enterado de lo que quiero decir. Si hablas de _sistemas de
inicio en uso_ son estas las que deben usarse _a partir de Jessie_:
systemd-sysv → votos: 34 %
sysvinit-core → votos: 2 %
upstart → testimonial, ni se acerca al 1 %
¿Significa eso que sysv sea menos usado que systemd? No, porque antes de
Jessie, sysvinit era quien contenía el sistema de arranque.
*Sospecho* que las cifras actuales de uso como sistema de arranque deben
andar por 66 % (sysv) y 34 % (systemd), con un matiz que añadir: No se
puede deducir la simpatía del usuario en ningún caso. En el primero
porque la práctica totalidad es de instalación obligatoria
(pre-Jessie), y en el segundo por lo que podríamos llamar "efecto
pereza" por ser el predeterminado. Popcon no puede usarse para eso. Sí
se puede (y era mi intención cuando lo mencioné) para señalar que
systemd no tiene un uso marginal [1], como es el caso de upstart.
> > Antes de Jessie la historia era otra. Y eso hay que tenerlo en
> > cuenta antes de interpretar las estadísticas. Me arrepiento de
> > haberlas mencionado.
>
> Menos mal :-P
>
> > Salvo que tengas otros datos fiables en que apoyarte, porcentaje de
> > instalación significa exclusivamente porcentaje de instalación.
>
> Pues mira, mejor que lo pones a sysvinit, que no sólo gana por
> goleada en los datos del Popcon a systemd sino que además tiene que
> luchar contra los datos de las instalaciones predeterminadas (las más
> habituales) porque a partir de Jessie no es fácil instalar el paquete
> sysvinit, hay que hacerlo a conciencia.
>
> > Cualquier otra interpretación tiene su riesgo. De hecho creo que el
> > uso principal para Debian (si no único) es elegir los más usados
> > para el CD
> >/DVD/loquesea de instalación.
>
> ¡Pues claro que tiene su riesgo! Los datos sin contexto no sirven
> para nada y Popcon no tiene en cuenta ningún tipo de contexto: sólo
> datos en bruto y nada más.
>
> ¹https://lists.debian.org/msgid-search/20150904214702.18d84...@gmail.com
>
> Saludos,
>
Saludos.
[1] https://lists.debian.org/debian-user-spanish/2015/09/msg00072.html
La primera mención en el hilo a popcon. Aquí me refería a systemd no
necesariamente como sistema de inicio pero equivoqué la cifra, el uso
corresponde al 38 %.
--
Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El sábado, 5 sep 2015 a las 15:20 UTC Camaleón escribió: > El Sat, 05 Sep 2015 17:06:48 +0200, Manolo Díaz escribió: > > > El sábado, 5 sep 2015 a las 14:57 UTC Camaleón escribió: > > > >> Hay paquetes que entran en conflicto con otros que proporcionan la > >> misma funcionalidad (p. ej., exim y postfix) y al menos en Wheezy no se > >> puede instalar upstart junto con sysvinit, no sé si en Jessie ya es > >> posible. > > > > Esos dos en concreto no. > > Ciertamente, ni con otros. Lo que quiero decir es que Popcon no permite > evaluar entornos fiables en el uso de paquetes porque algunos paquetes te > fuerzan a prescindir de otros aunque el usuario quiera tener los dos > instalados. Es decir, que no siempre refleja la realidad, sino sólo un > entorno forzado. > > > Pero para sysvinit y systemd-sysv (Debian > > testing actualizada, sin privilegios de administrador)... > > (...) > > No es un buen ejemplo: sólo faltaría que systemd no fuera compatible con > sysvinit, su inmediato antecesor, vamos, le hubieran caído chuzos de > punta a las distribuciones linuxeras que se hubieran pasado a systemd sin > tener retrocompatibilidad con el sistema anterior :-) Yo creo que sí, porque en todo momento se ha hablado de la cifra de instalación de sysvinit y systemd cuando resulta que (desde Jessie hasta el momento) los sistemas de inicio son sysvinit-core, systemd-sysv y upstart. Y esos tres sí que son incompatibles. De hecho tienes que elegir uno y solo uno. Antes de Jessie la historia era otra. Y eso hay que tenerlo en cuenta antes de interpretar las estadísticas. Me arrepiento de haberlas mencionado. Salvo que tengas otros datos fiables en que apoyarte, porcentaje de instalación significa exclusivamente porcentaje de instalación. Cualquier otra interpretación tiene su riesgo. De hecho creo que el uso principal para Debian (si no único) es elegir los más usados para el CD/DVD/loquesea de instalación. > Es decir, que es normal que estos dos paquetes "en concreto" se puedan > instalar conjuntamente (y esperemos que siga así por algún tiempo). > > Saludos, Saludos. -- Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El sábado, 5 sep 2015 a las 14:57 UTC Camaleón escribió: > Hay paquetes que entran en conflicto con otros que proporcionan la misma > funcionalidad (p. ej., exim y postfix) y al menos en Wheezy no se puede > instalar upstart junto con sysvinit, no sé si en Jessie ya es posible. Esos dos en concreto no. Pero para sysvinit y systemd-sysv (Debian testing actualizada, sin privilegios de administrador)... ~ apt install -s sysvinit systemd-sysv NOTA: ¡Esto es sólo una simulación! apt-get necesita privilegios de administrador para la ejecución real. Tenga también en cuenta que se han desactivado los bloqueos, ¡no dependa la situación real actual de la relevancia de esto! Leyendo lista de paquetes... Hecho Creando árbol de dependencias Leyendo la información de estado... Hecho Se instalarán los siguientes paquetes extras: libapparmor1 libcryptsetup4 systemd Paquetes sugeridos: systemd-ui systemd-container Paquetes recomendados: libpam-systemd Los siguientes paquetes se ELIMINARÁN: sysvinit-core Se instalarán los siguientes paquetes NUEVOS: libapparmor1 libcryptsetup4 systemd systemd-sysv sysvinit 0 actualizados, 5 nuevos se instalarán, 1 para eliminar y 0 no actualizados. Inst libapparmor1 (2.9.2-3 Debian:testing [amd64]) Conf libapparmor1 (2.9.2-3 Debian:testing [amd64]) Inst libcryptsetup4 (2:1.6.6-5 Debian:testing [amd64]) Conf libcryptsetup4 (2:1.6.6-5 Debian:testing [amd64]) Inst systemd (225-1 Debian:testing [amd64]) Conf systemd (225-1 Debian:testing [amd64]) Remv sysvinit-core [2.88dsf-59.2] [init:amd64 ] Inst systemd-sysv (225-1 Debian:testing [amd64]) Conf systemd-sysv (225-1 Debian:testing [amd64]) Inst sysvinit (2.88dsf-59.2 Debian:testing [amd64]) Conf sysvinit (2.88dsf-59.2 Debian:testing [amd64]) Y queda claro que sí. Saludos. -- Manolo Díaz
Re: Libertad o esclavitud. Elijan ¿"su" o “machinectl shell”?
El sábado, 5 sep 2015 a las 13:47 UTC Camaleón escribió: > El Fri, 04 Sep 2015 21:42:42 +0200, Manolo Díaz escribió: > > > El viernes, 4 sep 2015 a las 18:04 UTC Camaleón escribió: > > (...) > > >> https://qa.debian.org/popcon.php?package=sysvinit > > > > Veo un repunte últimamente en el gráfico. > > No me extraña lo más mínimo. > > >> Teniendo en cuenta que cualquier instalación predeterminada (y me > >> atrevería a decir que avanzada también) de Debian ≥8 te va a instalar > >> systemd, las estadísticas del popcon no son lo que se puede decir > >> "fiables" para medir la "popularidad" de este tipo de paquete. > >> > >> Por otra parte, el uso de popcon no requiere de una partición activa de > >> los usuarios sino que sólo envía automáticamente estadísticas de los > >> programas que se instalan/actualizan... > > > > ... y se usan con regularidad. > > Hombre, ya me dirás cómo no se va a usar con regularidad un gestor de > inicio >X-) No seas malvada. Se puede tener instalado pero usar otro. Lo que implica tener más de uno, claro. > > Y que no requiera de participación activa lo hace más fiable: no hay > > manipulación consciente. > > La hay porque son paquetes que se instalan por obligación: sí o sí. Si > eso no es manipulación... Sinceramente, nunca le vi utilidad real a > Popcon. No veo manipulación en saber de antemano que algo obligatorio, un suceso seguro, te va a dar 100 %. Lo preocupante sería que no. > Saludos, Saludos. -- Manolo Díaz
