#9900 es algo a lo que le doy vueltas tontamente xD Porque me pienso que no es correcto darle los hashes dentro del zip porque el archivo podría estar comprometido y esos hashes pueden ser cambiados por el "atacante". Entonces el cliente debería de fiarse de la fuente original (un correo, o un sitio web nuestro) y no lo que haya dentro del archivo.
Pues nah, instalando upstream de gentoo en una ps3 a ver si furrula docker y kubernetes xD.
De momento el SO con kernel nuevo está instalado y funcionando. No me ha costado ni trabajo hacer funcionar la puta cafetera.
#9899 ?
Igual no estoy entendiendo bien la pregunta pero los hashes los puedes dejar en los dos lados y diría a mqs importante es que estén fuera.
#9903
Si ya es lento el proceso de por sí, imagínate con 256 mb de ram y 265 de vram en swap.
No me atrevo a decir si funcionara kubernetes, de momento estoy actualizando el base system. Ya iré comentando por aquí la aventura.
#9905 pero y porqué quieres meterle kubernetes? Qué quieres tener la ps3 como servidor o qué? Un uso un tanto peculiar xD
#9899 Los hashes deberían ir por otro lado, porque si alguien modifica el paquete sin consentimiento, altera los hashes y nadie se da cuenta (si es que he entendido bien la pregunta).
#9901 Perdón, contesté antes de leer esto último. Puedes enviar los hashes cifrados por mail (Mailvelope por ejemplo).
Una pregunta, acabo de instalar arch linux en uefi (me ha costado más que en legacy por alguna cosa que tenía que hacer que he visto en algún vídeo que no en el manual oficial o no he sabido seguirlo), y para hacer ese paso del grub, he tenido que entrar con virtualbox y la imagen de arch, y hacer el arch-chroot y me he dado cuenta de que no me ha pedido passwd de root ni de nada, directamente ya root... por esa regla de tres, puedo ver todas las particiones y discos desde mi arch (ya que lo he instalado en un ssd externo de manera permanente para "llevarme el pc conmigo" para ciertas cosas de trabajo) y no veo yo muy seguro eso de montar particiones y ser root by the face, ¿no? ¿Qué me estoy perdiendo?
Creas un usuario y listo
Y le pones passwd al root.
Son dos pasos básicos de la instalación de Arch
Vale, no te había entendido. Ese mismo problema vas a tenerlo accediendo al disco duro desde un live. La solución es cifrar el disco
#9912 pero el chroot te permite ser root de la participación por la cara? Vas con un livecd por ahí y vas siendo root en todos los pc Linux? (A no ser que esté la partición cifrada)
#9913 Hombre cualquier cosa no encriptada es no segura.
Tu si tienes todo el fs en plano pues claro que puedes desde un live CD montarlo y hacer un chroot. En ningún momento eres el root de la máquina de verdad lo que pasa que tienes permisos igualmente para escribir en todos los lados y por lo tanto es lo mismo.
Para evitar estas cosas la solución es cifrar, que yo sepa en Linux en Windows y supongo que cualquier OS xD pero ni idea.
Pregunta:
Soy una persona a la que le gusta probar nuevas distribuciones muy de vez en cuando, tengo varios ordenadores pero siempre suelo usar el del curro como ordenador principal y además cambio mucho de curro (voy al que me den mejor ordenador xDDD).
La cosa es que siempre tengo mil configuraciones que aunque tenga mi repo de dotfiles y tal me las suelo hacer a mano y estoy hasta los cojones. Alguien me recomienda algo para migrar todo mi entorno de sitio a sitio de forma automatizada?
Lo unico que he pensado es en hacerme un playbook de ansible o algo así que me parece mas mantenible que hacer scripts pero si alguien tiene el mismo problema me gustaría saber lo que hace.
#9915 qué es exactamente lo que necesitas migrar? Yo con un bash script simplón que tengo y las dotfiles pilladas de github se hace solo. Se pueden mejorar muchas cosas pero lo hago una vez cada mil así que qué más me da al final.
También puedes probar nix pkg/nixos si te va el rollo pero es bastante denso.
#9915 En varios sitios he visto la opción de utilizar iAnsible para ello y es probable que yo lo haga para cuando cambio de portatil migrar todo para tenerlo igual en el nuevo. Pero no sé si al jugar con tantas distros distintas va a ser un quebradero de cabeza mantenerlo... Si cambias entre Debian-based y Redhat-based es mantenible, pero jugar con roles y playbooks para 5 distros distintas debe ser un quebradero de cabeza...
Todo depende del trabajo que te suponga mantenerlo y cada cuanto cambies/pruebes nuevas distros.
- Pues a ver en principio quiero instalar todo de forma automatica e independiente del sistema de paquetes (ej, apt, pacman, aur).
- Todas las configuraciones que es lo que dices tu (neovim, i3, tmux, zsh, profiles...).
- virtualenvs de python3
- COsas random que no me acuerdo, del estilo de ciertos workspaces de Go y basura mia.
Lo del script bash es algo que siempre he querido hacer pero es que me da una pereza tremenda, por eso habia pensado hacerme un rol de ansible, que puede ser hasta peor pero a nivel de tener ya ciertas cosas parametrizadas a la larga creo que igual es buena idea.
Voy a mirar lo que me has dicho lo use o no, thanks.
#9917 Pues si, es un poco quebradero de cabeza. Realmente me muevo entre debian based - arch based. Centos tb uso pero lo puedo eliminar d ela ecuación seguramente.
Pues yo justamente la ventaja que veo a Ansible es lo de poner tener en el playbook una fase de setup que dependa de una variable OS Family y dpeendiendo de esa instalar los mismos paquetes (en una lista) de una forma u otra.
Justo esto que acabo de comentar aunque no se si estaré en lo cierto, es lo que me parece mas engorroso de hacer en un script sobre todo por el alto riesgo de bugs.
Si con ansible sabes 100% que no tendrás edge cases de paquertes que no los conoce, palante. Al margen de la gestión de paquetes (que no es sólo que cambia el package manager, si no que pueden llamarse distinto), las cosas que dices son cuatro líneas en shell; piensa que el poco código que piques sería para llamar a binarios/scripts (en python con virtualenvwrapper lo gestionas todo fácil por ejemplo).
Ansible para cuatro dotfiles roñosos me parece overkill xD
Casi que te renta más copiarlos a mano xDD
#9920 Hombre si solo son 4 dotfiles desde luego.
#9918
Si la cosa es aparte de los dotfiles instalar una serie de paquetes, drivers y alguna otra cosa más es para pensárselo. Al final todo depende de cada cuanto pruebas una distro nueva y si merece la pena invertir el tiempo que tardas en ponerla más o menos como te gusta, en crear algo que lo haga más o menos automático. Moviéndose mayormente entre Debian, Arch, Centos no debería ser algo que llevase mucho tiempo. Y bueno si nunca has tocado Ansible y te interesa darle un tiento nunca está de más para empezar 
#9919 Tienes razon en lo de los paquetes, ni lo habia pensado sobre todo por cambios de nombre.
#9920 a mano llevo tirando cierto tiempo, y tengo ya muchisimas cosas interiorizadas pero es que es un coñazo.
#9921 No soy ningun experto de Ansible pero si que lo he tocado. Aunque con bash tengo ya bastante trayectoria es que me fio mas de ansible xD.
La verdad es que en este hilo os veo a muchos que entiendo que sois maquinas de bash, yo creo que me defiendo bastante pero Ansible me parece incluso mas facil, hace poco migré un script de provisionamiento de unas ~ 70 lineas (una mierda) a ansible y me costo -4 (obviamente desglosandolo en modulos y eso).
Ahora mismo creo que estoy un 65% ansible 35% bash jajaja. Es un problema que me urge debido a que me piro del curro así que me decidiré dentro de poco.
Gracias por las respuestas.
A mi en alguna actualización de plasma me ha jodido toda la configuración. Me han desaparecido los efectos de kwin, latte... , y mis logs son una interminable lista de warnings.
Tengo que ponerme a ver si lo consigo apañar, pero me da menos pereza empezar de cero que toquetear los dotfiles.
Como para cambiar de distro con la consiguiente diferencia de versiones de paquetes.
rm -rf .config
Me voy a tener que acostumbrar a usar el pacman menos a menudo.
#9922 por lo que te comenta #9919 es por lo que te decia que manejar playbooks o roles para 5 distros distintas puede llegar a ser un quebradero de cabeza, tienes el módulo "package" que te vale para que no tengas que andar con el módulo de gestor de paquetes (apt, yum, con AUR no te va a funcionar), pero vas a tener que definir variables para los paquetes que no se llaman distinto en cada distro y sus versiones. Si solo instalas 20 paquetes pues igual no hay inconveniente... si instalas 2000...
El mayor problema aquí a mi modo de ver es lo que comenta #9923 diferencias de versiones de paquetes y dotfiles específicos para una versión, etc... que luego puedan ocasionar más problemas que el tiempo que te supone instalarlo "a mano".
Es que depende de lo que haga el script en bash al final, pero lo que dices básicamente sería:
- instalar el core más mínimo (git, curl, etc)
- hacer pull de las dotfiles y ejecutar cualquier script de setup que tenga
- instalar desde el pkg manager
- instalar desde source (curl/wget source en github/repo git random y el make)
- esqueleto básico de X movidas de entorno, como virtualenvwrapper de python o el que sea que uses con go
Cada paso son máximo 5 líneas de bash si lo quieres hacer perro sin gestionar los errores y demás.
yo sigo proponiendo nix (el pkg manager no el os) porque por qué no
https://nixos.org/manual/nix/stable/#chap-package-management
Una pregunta, como comenté atrás estaba queriendo meter en un disco duro portátil una partición con disco de Linux (he probado arch y Ubuntu) la cosa es que a veces se "freezea" y muere, como que el USB pierde la conexión y por tanto a tomar por culo el so. Reinicio bruto pulsando botón físico de apagar y a seguir.
A veces es al minuto, a veces a la hora, a veces nada...
¿Por qué creéis que es? Me pasa en al menos 3 pcs que he probado.
Me da que mi idea de "ordenador portátil" en SSD mini es un fracaso 
#9927 no, pero pensaba que el SSD sería bueno por velocidades de escritura y lectura en USB 3.0 pero mira.. se ve que microdesconexiones que hacen que se bloquee el pc y ale, reinicio..
#9928 Puede que el SSD sea bueno pero la carcasa no lo sea. No sé si has cogido un SSD y una carcasa o una solución ya de fábrica SSD+carcasa USB, la verdad.
Vamos, yo he tenido hace 10 años o más un linux en un good old HDD de 2.5" por usb 2 y, aparte de ir lento como su puta madre, funcionaba todo perfecto.
#9929 y nunca congelaciones? Vamos que la idea que tengo es buena y si falla es por el SSD.
Probaré en otro disco a ver.
Voy a probar de paso KDE neon.
