Mejores publicaciones hechas por cobito

@jordiqui A ver cómo va este. El anterior Xeon quedó a la altura de un Ryzen 7 5800X en multihilo, lo cual no está mal teniendo en cuenta la edad y que no tiene AVX2.

Qué envidia esos 64 GB de RAM. Quien los pillara.

@mangazo Las condiciones para que el adaptador funcione es que tenga exactamente la misma tensión (voltios) y pueda dar al menos la misma corriente (amperior) o más. En la lista que pones, el único que va a funcionar es el de 3V y 1200mA porque la tensión coincide con la que necesita tu dispositivo y la corriente que puede suministrar es superior.

Las fuentes de 5 y 6V van a quemar tu aparato. Ten en cuenta también las polaridades de salida. Suele haber un diagrama de este estilo.

En este caso, la parte central del conector es positivo y la exterior negativa. Es fundamental que esto coincida con la fuente original o con la etiqueta de características del dispositivo en cuestión.

Este hilo forma parte de la guía para montar un servidor en Debian.
Recuerda que el contenido de Hardlimit está bajo licencia Creative Commons.

---

Una vez que tenemos el archivo .htaccess operativo, podemos empezar a usarlo para algunas cuestiones prácticas que se explican a continuación.

Bloquear el acceso a una página con .htaccess

Una de las posibilidades que nos permite el archivo .htaccess es impedir el acceso a una subcarpeta o archivo de nuestro servidor web.

Si todavía no disponemos de un archivo .htaccess, lo creamos en la subcarpeta donde queramos que tenga efecto.

touch /var/www/html/subcarpeta/.htaccess
nano /var/www/html/subcarpeta/.htaccess

Para bloquear el acceso a un archivo, pegamos al final del archivo el siguiente texto:

<Files archivo.html>
   deny from all
</Files>

Para impedir el acceso a una carpeta, pegamos esto:

<Directory /var/www/html/subcarpeta/bloqueada>
   deny from all
</Directory>

Mover página de dirección

En alguna ocasión es posible que queramos mover nuestra web de dirección, ya sea porque queremos cambiarle el nombre, porque queremos pasar de un subdominio y a un dominio o cualquier otra razón.

Para que los robots de búsqueda y los usuarios puedan seguir accediendo al contenido sin tener que conocer la nueva dirección, podemos redireccionar todo el contenido al nuevo dominio. De esa forma, los navegadores web y robots recibirán un código de estado 301 moved permanently lo que indica que el sitio ha sido movido.

Lo único que tenemos que hacer es crear un archivo .htaccess en la subcarpeta donde se encuentra la web:

touch /var/www/html/subcarpeta/.htaccess
nano /var/www/html/subcarpeta/.htaccess

Finalmente pegamos este texto:

Options +FollowSymLinks
RewriteEngine on
RewriteRule (.*) https://nuevo_dominio.com/$1 [R=301,L]

Lo único que debemos modificar es el dominio de nuestra nueva web. Ahora cada vez que alguien acceda a la antigua dirección, será redireccionado inmediatamente a la nueva y los robots de búsqueda sabrán que el sitio ha sido movido.

Habilitar caché del navegador

Si habilitamos la caché del navegador con Apache, nos ahorraremos una gran cantidad de ancho de banda cuando tengamos que servir ciertos elementos y por otra parte, al cliente le cargará la página mucho más rápido. No obstante, hay que tener en cuenta que si permitimos el cacheo de ciertos archivos, el cliente podría estar visualizando contenido sin contactar con el servidor, por lo que serían visitas no contabilizadas. Además, si hay ciertos elementos que cambian con frecuencia, en el caso de que se haya accedido previamente a ese recurso, los cambios no se visualizarán hasta que expire la caché.

En primer lugar activamos el módulo expires y reiniciamos Apache como root:

a2enmod expires
/etc/init.d/apache2 restart

Si no contamos con un archivo .htaccess, lo creamos:

touch /var/www/html/subcarpeta/.htaccess
nano /var/www/html/subcarpeta/.htaccess

Y añadimos el siguiente texto:

<IfModule mod_expires.c>
   <filesmatch "\.(jpg|JPG|jpeg|JPEG|gif|GIF|png|PNG|css|ico)$">
      ExpiresActive on
      ExpiresDefault "access plus 30 day"
   </filesmatch>
</IfModule>

Los parámetros que nos interesan son estos:
· filesmatch: ahí se indican las extensiones de los archivos que se van a almacenar en la caché del navegador. No añadas la extensión html ya que son archivos que consumen poco caudal y cualquier modificación no surtirá efecto en la visualización hasta que caduque la caché.
· ExpiresDefault "access plus xx day": se indica la cantidad de días que se almacenará la caché. Cuanto más tiempo, menos se repetirán los envíos de ciertos archivos a visitantes habituales pero más tardarán en poder visualizar los cambios producidos en esos archivos.

@sinchan2 Me alegra que pueda servir de ayuda. A ver si tengo un poco de suerte y puedo sacar tiempo las dos próximas semanas para darle un empujón.

Por cierto, bienvenido después de 13 años.

Este hilo forma parte de la guía para montar un servidor en Debian.
Recuerda que el contenido de Hardlimit está bajo licencia Creative Commons.

---

Procedimiento

Como root:

nano /etc/apache2/sites-available/000-default.conf

Usar como plantilla esto:

<VirtualHost *:80>
   DocumentRoot "/home/Servidor/hardlimit.com/"
   ServerName hardlimit.com
   ServerAlias hardlimit.com
   CustomLog ${APACHE_LOG_DIR}/access_hardlimit.log combined
</VirtualHost>

nano /etc/apache2/apache2.conf

Eliminar todas las secciones Directory que encontremos en el archivo.

/etc/init.d/apache2 restart

Explicación

Si queremos acceder a páginas diferentes desde dominios o subdominios diferentes con un único servidor y una única IP pública, debemos usar servidores virtuales (VirtualHosts). Desde aquí no solo es posible decirle al servicio qué página debe abrir según con qué dominio reciba la petición, sino que es el lugar para elegir el directorio local donde se almacena la web.

Los servidores virtuales se configuran en en el archivo '000-default.conf' por lo que habrá que ejecutar como root esto:

nano /etc/apache2/sites-available/000-default.conf

En ese momento, el archivo se abre con Nano e inicialemente nos vamos a encontrar con el siguiente texto:

Las lineas que aparecen para configurar son:
· ServerAdmin: correo electrónico del administrador
· DocumentRoot: carpeta local donde se almacena la web
· ErrorLog ruta donde se registran los errores del servidor

Tal y como está el archivo inicialmente, sea como sea que accedamos al servidor desde un navegador web (desde cualquier dominio apuntando a la IP), se mostrará la página a la que apunta DocumentRoot.

Una buena plantilla para un par de servidores virtuales puede ser como la que sigue:

<VirtualHost *:80>
   DocumentRoot "/home/Servidor/portada/"
   ServerName hardlimit.com
   ServerAlias hardlimit.com
   CustomLog ${APACHE_LOG_DIR}/access_hardlimit_com.log combined
</VirtualHost>
<VirtualHost *:80>
   DocumentRoot "/home/Servidor/banco_pruebas/"
   ServerName bm.hardlimit.com
   ServerAlias bm.hardlimit.com
   CustomLog ${APACHE_LOG_DIR}/access_bm_hardlimit.log combined
</VirtualHost>

Poniendo el nombre del dominio tanto en las opciones ServerName como ServerAlias, la página mostrada desde ese dominio será la que apunta DocumentRoot. En el caso de que no coincida, se servirá la web que aparezca en el primer VirtualHost de la lista.

En esa plantilla, vemos dos secciones VirtualHost: una para atender las peticiones desde el dominio raíz hardlimit.com otra para el subdominio bm.hardlimit.com. Cada una tiene sus configuraciones independientes y se pueden añadir tantas secciones VirtualHost como sean necesarias.

Como hemos configurado nuestros sitios individualmente, las configuraciones genéricas del archivo apache2.conf las debemos eliminar para que no entren en conflicto. Para eso:

nano /etc/apache2/apache2.conf

Ahora eliminamos todas las secciones 'Directory' que encontremos en el archivo. Con eso nos aseguramos de poder usar cualquier carpeta diferente a /var/www/html que viene por defecto.

Para que se apliquen los cambios, deberás reiniciar Apache desde root con:

/etc/init.d/apache2 restart

Pero ¿cómo funciona todo esto? El proceso es el siguiente:
· Escribes hardlimit.com en el explorador web.
· Tu ordenador le pide al servidor DNS la IP de dicho dominio.
· Tu ordenador se conecta a dicha dirección IP y dice al servidor web que quiere comunicarse con hardlimit.com (esta información está contenida en el encabezado Host de la petición HTTP).
· Nuestro servidor web comprueba la configuración para averiguar qué contenido ofrecer con esa petición.
· Si hardlimit.com está como parámetro de ServerName o ServerAlias en una sección VirtualHost, se ofrece el contenido de lo que haya en la ruta DocumentRoot. Si no la encuentra, ofrece lo que diga el primer VirtualHost de la lista. Si no existe ningún VirtualHost, recurre a la configuración almacenada en el archivo de configuración de Apache que se encuentra en /etc/apache2/apache2.conf.

Este hilo forma parte de la guía para montar un servidor en Debian.
Recuerda que el contenido de Hardlimit está bajo licencia Creative Commons.

---

Procedimiento

Como root:

nano /etc/network/interfaces

sustituir las últimas dos lineas por:

auto enp0s3
 iface enp0s3 inet static
 address nuestra_ip_local
 netmask máscara_de_subred
 gateway puerta_de_acceso

NOTA: Recuerda que enp0s3 es el nombre de tu dispositivo de red y que este puede ser diferente al del ejemplo. Para saber el nombre de tu dispositivo de red, puedes escribir en consola:

ip a

Para terminar:

reboot

Explicación

Debido a la naturaleza del sistema (un servidor), es esencial contar con una IP local fija ya que nuestro router redireccionará los puertos a dicha IP. Si esta cambiara, nuestro servidor quedaría irremediablemente incomunicado con el exterior.

Para configurar una IP local estática vamos a editar el archivo 'interfaces'. Para ello, como root, escribimos lo siguiente:

nano /etc/network/interfaces

Nos vamos a encontrar con esto:

Tan solo tenemos que sustituir las dos últimas lineas por:

auto enp0s3
iface enp0s3 inet static
address nuestra_ip_local
netmask máscara_de_subred
gateway puerta_de_acceso

· address indica la IP del dispositivo de red conectado a Internet. Deberá cumplir con la norma para evitar conflictos con direcciones IP públicas. Las direcciones privadas normalizadas están divididas en tres clases: clase A de 10.0.0.0 a 10.255.255.255, clase B de 172.16.0.0 a 172.31.255.255 y clase C de 192.168.0.0 a 192.168.255.255. La más extendida es la clase C.
· netmask es la máscara de subred. Habitualmente vale 255.255.255.0.
· gateway es la puerta de acceso predeterminada, es decir, la dirección IP local del router desde el que nos conectamos a Internet.

Ten en cuenta que enp0s3 es el nombre de tu dispositivo de red y que este puede ser diferente al del ejemplo. Para saber el nombre de tu dispositivo de red, puedes escribir en consola:

ip a

En mi caso, el archivo de configuración quedaría de esta forma:

Una vez introducidos los cambios en el archivo de configuración, lo guardamos y salimos de Nano. Para aplicar los cambios debemos reiniciar el sistema empleando la siguiente instrucción como root:

reboot

Cuando se ha reiniciado, comprobaremos que la IP de nuestra máquina será la que hemos introducido. Evidentemente, para reconectarnos con SSH deberemos tener en cuenta este cambio:

Este hilo forma parte de la guía para montar un servidor en Debian.
Recuerda que el contenido de Hardlimit está bajo licencia Creative Commons.

Resumen

Instala la edición 'Netinst'.

Explicación

Debian se distribuye en numerosas ediciones, ya no solo en formatos (CD, DVD, BD) sino en el contenido de cada versión. En nuestro caso queremos instalar el sistema más básico posible, sin entorno de escritorio y sin apenas servicios de serie, por lo que usaremos el edición 'Netinst' compilada para AMD64. Se trata de una imagen que ocupa unos 600Mb y que descarga de los repositorios oficiales los paquetes necesarios durante la instalación.

PCs viejos

Si quieres aprovechar un PC con unos años a sus espaldas, quizás quieras reconsiderar la arquitectura de la compilación, es decir, ¿32 o 64 bits?

Esta es la pregunta del millón que todo el mundo se ha hecho en alguna ocasión. La respuesta rápida y típica es: si tienes menos de 4 GB de RAM, usa 32 bits y si tiene 4 GB o más, instala la de 64 bits. Se trata de una respuesta que técnicamente no es incorrecta pero sí demasiado simple. Puede haber entornos en los que con menos de 4 Gb de RAM, un sistema operativo de 64 bits ofrezca un mejor resultado. Por ejemplo, está más que demostrado que la codificación de vídeo tiene un aumento de rendimiento significativo en sistemas de 64 bits. Y sí, puede haber entornos con 4 o más Gb de RAM donde los 32 bits ofrezca un mejor resultado.

Alguno se preguntará qué sentido tiene instalar un sistema operativo de 32 bits en una máquina con más de 4 GB de RAM cuando con direcciones de 32 bits no se puede acceder a más de esa cantidad de memoria. Desde hace bastante tiempo, todos los procesadores x86 incluyen una característica llamada PAE (Physical Address Extension o extensión de memoria física). Con esta técnica, un procesador trabajando en 32 bits puede direccionar hasta 64 GB de RAM. Evidentemente, esto tiene truco y el truco está en que no se pueden manejar hilos de ejecución de más de 4 GB, por lo que si un proceso quiere acceder a más de esa cantidad, tendrá problemas.

Una vez solucionado el problema de la cantidad de memoria, ¿por qué en nuestro servidor, 32 bits nos podrían ofrecer mejores resultados? Supongamos que el programa más exigente que va a estar funcionando es el servidor web Apache.

32 vs 64 bits en un Core 2 Duo. Fuente: Phoronix.

Tal y como vemos en el banco de pruebas realizado por Phoronix, Apache compilado para 32 bits obtiene un resultado ligeramente superior. En otros artículos se puede comprobar que esta afirmación se mantiene.

La razón por la que existe esta pequeña diferencia de rendimiento es que las direcciones de memoria de 64 bits ocupan el doble que las de 32, por lo que si el programa no hace un uso intensivo del repertorio de instrucciones x86_64 (AMD64 o Intel 64), esa cantidad extra de datos a mover resiente ligeramente el rendimiento.

Esta diferencia se aprecia también en procesadores relativamente recientes aunque las distancias se acortan.

32 vs 64 bits en un Core i7 720Q. Fuente: Phoronix.

Además hay que tener en cuenta que los 32 bits ofrecen una mayor compatibilidad con bibliotecas 'legacy'. Por último cabe destacar que los procesos lanzados por Apache, apenas llegan a varias decenas de megabytes, por lo que alcanzar el límite de 4 Gb se antoja muy complicado.

Evidentemente si tu máquina tiene más de 64 Gb de RAM o vas a necesitar que los procesos puedan acceder a más de 4GB de RAM (algo relativamente normal en plataformas NodeJS y Redis, por ejemplo), no tienes más remedio que instalar un sistema operativo de 64 bits.

Ahora bien, en el uso en el escritorio, las ediciones de 32 bits apenas se usan en la actualidad. Eso quiere decir que la cantidad de usuarios con sistemas de 64 bits es muy superior al de usuarios con sistemas de 32 bits. Esto redunda en que existe un mejor soporte en sistemas de 64 bits ya que hay más ojos a la caza de fallos. Algunas distros han decidido abandonar los 32 bits y la realidad es que las compilaciones para procesadores de 32 bits son una especie en peligro de extinción.

Por eso, al instalar Debian compilado para 32 bits no son todo ventajas y debes sopesar bien qué opción te conviene más teniendo en cuenta que la tendencia es a abandonar la antigua arquitectura.

@desvest Lo del certificado de Youtube huele a chamusquina. Configura una DNS manual en Windows, reinicia el navegador y vuelve a probar. La DNS de IBM (9.9.9.9) es una buena opción.

@Infocarri dijo en no consigo driver para lector dni usb en xubuntu:

Sveon SCT012-N

¿Qué versión de Xubuntu estás usando? Parece un lector con algunos años ya. Mira a ver si poniendo en consola lsusb, aparece en la lista.

@Clipper Pues para lo del USB no tengo una explicación. Yo he tenido problemas con el USB 3.algo en un portátil de hace 2 o 3 años incluso usando una versión muy reciente del kernel. Pero con USB 2.0 jamás. Sólo se me ocurre un fallo físico de la controladora (lo cual me parece raro dado que supongo que estabas usando esos puertos hasta que te petó el SSD) o que tenga una controladora rara que use controladores propietarios, algo que desde luego nunca he visto.

Sobre la BIOS, ni idea. A ver si alguien te puede arrojar algo de luz por ahí.

@Clipper Parece un fallo de la herramienta de formateo de Debian (la misma que usa Ubuntu) que aparentemente sale cuando se usan unidades USB. Un fallo, por cierto, que lleva casi 8 años estando ahí, que tiene narices la cosa.

En fin, la solución más sencilla es que instales Gparted (una herramienta gráfica para gestionar particiones). Desde ahí tienes que desmontar la unidad que quieras formatear y luego le das formato. A partir de ahí, no deberías tener problemas en instalar Ubuntu.

@Clipper

@Clipper dijo en Ssd muerto como cargo el s.o:

Por razones extrañas no me deja "machacar" el 10.10 y me da error en el instalador .

Si no tienes datos importante en la partición de Ubuntu 10.10, elimínala y vuélvela a crear. No te recomiendo hacer la instalación sobre la anterior y menos cuando son dos versiones tan separadas en el tiempo.

Sobre el ratón en el USB 3, tengo curiosidad, ¿lo estabas pinchando en un USB 2.0 y no funcionaba?

@radge Lleva una GPU todalmente de Intel. Suponiendo que estás usando una versión reciente de Lubuntu, todo el hardware que lleva ese equipo lleva bastante tiempo teniendo soporte en el kernel, en principio sin necesidad de módulos externos. Si la bios te deja elegir entre modo de Sata Ide o AHCI, cámbialo esté como esté, a ver si notas alguna diferencia.

Precisamente por llevar una iGPU de Intel, debería ir bien a no ser que sea una PowerVR. Si lleva una GPU totalmente de Intel, el problema debe estar en otro sitio. Cuando está arrancando, ¿se tira esos dos minutos en el logo de inicio, dentro de Xorg, con partes del escritorio ya cargadas...?

¿Qué portátil es?

Por si la noticia lleva a error, Valve va a dejar de dar soporte a Ubuntu, pero va a seguir produciendo Steam para Linux. El resto de distribuciones han estado empaquetando el cliente y sus dependencias desde el primer momento que es lo que tendrá que hacer Canonical a partir de ahora. Seguramente durante unos meses los usuarios de la distro tendrán algunos problemas en la transición, pero nada que no se soluciones en futuras versiones.

Cuando salió Steam para Linux, en Mageia no era tan fácil hacerlo funcionar si no usabas repositorios extraoficiales y aún así había problemas. Desde hace tiempo, instalarlo es tan sencillo como instalar el paquete mantenido por Mageia.

En mi caso uso Virtualbox porque es cómodo, fácil, es FOSS y está disponible para Linux y Windows. Eso me permite usar una misma máquina virtual en cualquier sistema operativo lo cual me resulta cómodo para ciertas cosas. Pero Virtualbox no es el más rápido. He leído (aunque no probado) que QEMU con KVM (sólo en Linux) consigue un rendimiento cercano al hardware huésped. Y aunque seguramente no te resulte práctico, existe la posibilidad de hacer passthru a la GPU y tener acceso directo al hardware, con lo que el rendimiento en juegos sobre máquina virtual es prácticamente el mismo que sobre el hardware real.

No conozco el resto de programas que mencionas así que sólo te puedo decir eso: si quieres algo fácil, cómodo y versátil Virtualbox te va a servir. Si quieres exprimir el hardware al máximo, el host es Linux y no te importa dedicar unas horas a documentarte y preparar la máquina virtual, entonces QEMU + KVM.

Daniel Stori ha publicado esta ilustración en turnoff.us donde se pueden ver los componentes más relevantes de Linux representados por simpáticos personajes

Hoy se ha actualizado Peertube a 7.1.1 por fallos de seguridad cuyos detalles se desvelarán este marte. Además, al cambiar de revisión también se han incluido nuevas características. Para su actualización, ha sido necesario saltar a nodejs 20, algo que afecta al foro de forma tangencial y no debería notarse.

Mastodon va a seguir fuera de servicio unas horas porque el contenido se está moviendo de unidad de almacenamiento y la estructura de directorios es un despropósito absoluto. Espero que para esta noche esté todo listo.

Editado: Mastodon ya está en linea.

@vreyes1981 Buenas. El museo se deshabilitó hace unos días debido a una serie de "ataques" que se han estado recibiendo por parte de bots malos. Han estado cebándose con todas las páginas y el otro día le tocó al museo.

Ya está habilitado de nuevo.

Sobre subir los CDs, ¿cuántos tienes? ¿cuánto ocupan? No existe una forma oficial de subir material. Te habilitaría una cuenta de Nextcloud (una especie de Dropbox) donde podrías subir el material para luego catalogarlo y publicarlo.

Gracias.

@krampak dijo en Información & anuncios:

Madre mía, qué odisea jefe!

Pues sí, esta vez ha sido duro. Muchos servicios y cada uno de su padre y de su madre.

@Fassou dijo en Información & anuncios:

Este es Atlas cargando con la bóveda celeste, o @cobito levantando el servidor, ahora no me acuerdo

Un grande!

Si Atlas estuviera hecho un tirillas, lo mismo habría duda

@Sylver dijo en Información & anuncios:

Qué vergüenza no poder devolverte ni una ínfima parte de lo que haces por nosotros @cobito... Menudo currazo

De una forma u otra, parece que Debian sigue rodeado de peligros como ya me dijese aquel profesor de informática hace años... Pero apuesto lo que sea a que él no tuvo que enfrentarse a tantos añadidos como en este caso.

En fin, un millón de gracias como siempre, y espero poder contribuir como buenamente pueda con la causa.

¡Saludos!

Vergüenza ninguna. Con que os paséis de vez en cuando a mirar, ya va bien. Debian no es la más fácil aunque esta vez ha sido más mala suerte que otra cosa.

Bueno, pues en principio, ya está todo funcional. He visto que incluso se han solucionado problemas que había a la hora de visualizar las revistas del museo (un problema que había que la versión de Imagemagick anterior) y las emulaciones vuelven a funcionar (algo raro que hacía Nginx que no supe arreglar).

Al foro todavía tendré que darle una vueltecilla con el CSS.