ice

Miembros
  • Contenido

    314
  • Registrado

  • Última Visita

  • Días Ganando

    17

ice ganó por última vez en Septiembre 24

¡ice tuvo el contenido mejor valorado!

2 Seguidores

Sobre ice

  • Rango
    Linuxero
  • Cumpleaños 19/01/84

Género

  • Género
    Hombre

Características del sistema

  • Distribución
    ArchLinux
  • Entorno gráfico
    OpenBox
  • Navegador Web
    Chrome
  • Distribución secundaria
    Slackware
  • Entorno gráfico secundario
    Sin_especificar
  • Navegador Web secundario
    Firefox

Información de contacto

  • Página Web
    https://linuxforallsite.wordpress.com
  • Youtube
    https://www.youtube.com/icetremens
  • Email
    ice.modding@gmail.com

Información personal

  • Lugar
    Tucumán - Argentina
  • Intereses
    Música, Guitarras, Informática, Linux, Hacking, Phreak, Cracking, PHP, Desarrollo Web, Android y muchas cosas más...

Visitantes recientes en el perfil

367 visitas al perfil
  1. De acuerdo a la polémica que viene hace mucho, pero que vengo leyendo hasta el día de hoy en grupos de Telegram como el de mi amigo José que se llama GNU/Linux sin systemd. Tenía ganas de escribir algo de ésto también, tal vez crean que es lo mismo que se ve en todos los blogs, twitter, youtube, grupos de telegram, etc. No! nada que ver, trataré de ser lo más objetivo sobre éste init (systemd) y las demás alternativas que tenemos actualmente para instalar o las diferentes distribuciones sin éste init, con sus pro y sus contra. Me basaré en la experiencia del usuario "normal" y también para los usuarios de nivel medio/avanzado para no dejar de lado ésa parte que es la que mayores controversias traen actualmente. Comencemos! Introducción: De las preguntas que uno se hace ¿Porqué prácticamente todas las distribuciones de GNU/Linux la implementaron?. ¿Si es tan conflictivo porque lo adaptan las distribuciones más conocidas como Archlinux o Debian? Yo creo que el tema viene (siempre hablando desde mi humilde opinión de usar Archlinux, haber usado Debian, Ubuntu, Linuxmint, Slackware, Void, etc.) para no perder campo en el terreno de como ser gnome-shell, que como sabemos necesita si o si systemd y dependencias en ocaciones que nadie sabe porqué!. Si seguimos con la misma idea, también nos vamos a poner a pensar que entonces: ¿Porqué Slackware y Void no usan systemd? Tantas preguntas nos hacemos a la hora de tratar de "hilar fino", sinceramente creo que realmente no hay, no existe y no habrá una resputa concreta del porqué, pero podemos hablar de los pro y contra de usar un init implementado prácticamente a la fuerza y de los demás que podemos usar como alternativa o diractamente migrar a otra distro, como las antes mencionadas como ser una de las más longeva en el mundo GNU/Linux que es Slackware Linux Project y otra que no es longeva, lleva sus años, pero le falta más trabajo como ser Void Linux. ¿Qué es systemd? Éste es un sistema de inicio de nuestro núcleo, nuestro llamado kernel, creado por el tan controversial Lennard Poettering junto a otros desarrolladores que trabajan para la distribución tan conocida como es Red Hat, actualmente con una licencia LGPL 2 que se encuenta en Github. Básicamente systemd es un "programa" que se encarga de administrar nuestro sistema a través de servicios en el arranque de nuestro equipo gestionando todos los procesos. Además nos permite trabajar de manera simultánea y liberar otras tareas de nuestro shell y trabajos de nuestro hardware. Aquí dejo un link de la wiki con más detalles. Después de una "larga" introducción, pasamos a la parte del manejo de los procesos del que se encarga systemd. Entonces que es un proceso? Un proceso es lo que nuestro sistema lo identifica como PID (Process ID). Cada proceso tiene una función específica sobre la tarea que realiza en nuestro sistema. Éstos pueden crear otros procesos llamados procesos "hijos". Sabiendo ésto, nos preguntamos ¿Cómo se maneja entonces SystemD? Bueno éste init se encarga de manejar los servicios de manera simultánea, ya que se encarga de administrar éstos creando sockets para cada servicios, ¿Qué significa ésto? Que cada servicio está cargado en la memoria, pero sin activarse hasta ser necesario. Si nos ponemos a pensar de que lo anteriormente nombrado se podría tomar como una ventaja entonces podríamos decir que también systemd utiliza los cgroups (Control Groups) que tiene por ejemplo Openrc (Luego hablaré de éste). Y además que si decimos que SystemD se maneja con los "units" (si leyeron la wiki al comienzo van a entender) son archivos de: * Configuración de servicios. * Puntos de montaje. * Sistemas de archivos. * Swap. * Entre otras cosas más que pueden investigar. Cada unit posee características para cada recurso utilizado, el cuál nos da la posibilidad de manejar ése recurso independientemente a otro. La manera en que se maneja éste sistema nos permite hacer otras cosas más como reemplazar, eliminar o reiniciar procesos que vemos necesarios o no. Systemd comparado con otros inits con los que considero que son con los que tuve mejor experiencia como usuario común y menejando mis servidores. Openrc: Elegí el ejemplo del init Openrc, porque después de SystemD es de los más conocidos por usuarios más "veteranos" en éste sistema. ¿Qué es Openrc? Básicamente es un sistema de inicio que es compatible con BSD, SystemV mantenido por los mismos desarrolladores de Gentoo y está basado en dependencias. Que cuenta con ventajas también es como systemd permite el inicio de los procesos simultáneo. También es posible utilizar Openrc junto a otros kernels además del GNU/Linux, claro está que también como lo mencioné anteriormente con procesos como son cgroups. Los que prefieren éste init (que a mi entender entre las alternativas es el más completo) es que posee lo siguiente: * El código de OpenRC está escrito en lenguaje POSIX. * OpenRC no depende de D-Bus. * La flexibilidad a la hora de configurar. * El modo de depuración detallado. * Entre otras características que deberán documentarse al respecto. Runit: Runit es el init por defecto que trae ésta distribución (áún le falta para jugar en primera con las grandes) Void. Éste init es un conjunto de herramientas que tambén incluyen un init PID 1, así como un sistema de chequeo de procesos compatibles con deminios y utilidades que nos agilizan la ejecución de procesos, así también la creación de los mismos y el mantenimiento. Además creo que algo que destaco obviamente de su simpleza es el "concepto" de un directorio de servicios que se encarga de manejar los servicios individualmente y obviamente de tener todo registrado perfectamente. En el caso que quieran saber un poco más tenemos la wiki de VoidLinux aquí. Entonces finalmente ¿SystemD, OpenRC, Runit o cuál? La idea de utilizar el un init en particular depende pura y exclusivamente para el uso que le daremos a nuestro o nuestros equipos. En éste caso daré mi opinión (humilde) como usuario normal que sólo estoy para aprender. A la hora de utilizar una distribución siempre voy por las principales o llamadas "distribuciones madres", como son Archlinux, Debian, Slackware, Void. De las cuatro mencionadas las tengo instaladas a las cuatro y dos de ellas (Arch y Debian) utilizan SystemD, lo cuál no me resultó para nada complicado comenzar a utilizarlo desde cero, es más hasta me pareció muy simple sin mayores problemas en lo que van los años que lo uso. Ahora con respecto a las otras dos distribuciones restantes Slackware y Void, conociendo los años de historia que nos trae Slack en el mundo GNU/Linux tuve la mejor experiencia con el init que utiliza que es el propio de la misma distribución (basado en BSD directamente), ya que jamás modificaron sus filosofías o manera de manejarse, entonces no me resultó complicado tampoco volver a utilizarlo, activar, desactivar, habilitar, deshabilitar servicios, etc. Finalmente quiero hacer un punto aparte con el init de Void Linux, la verdad que fué una grata sorpresa utilizar un init así, como lo voy a escribir ahora, un "init realmente simple de manejar". Hasta parece que está pensando a prueba de torpes. Desde el primer momento que lei como manejarlo, quedé impresionado. Para los que recién comienzan con GNU/Linux hasta les recomendaría Void, más allá que aún le falta mucho para estar al lado de las grandes distribuciones, nos da una simpleza a la hora de manejarla que te deja tranquilo. Asi que entonces volviendo a la pregunta con ¿Cuál init me quedo? Yo lo que haría sería, preguntarme para que necesito otro? - Tuve problemas con el init que tengo actualmente? Si/No. - Me resulta sencillo de manejar? Si/No. - Me hace falta instalar otro? Si/No. También tenemos la alternativa si tenemos tiempo y ganas de virtualizar y utilizar otras distros como las que les mencioné y fijarse si realmente se sienten más cómodos, les resulta igual, mejor o peor! El mejor consejo que les puedo dar es que la decisión es sólamente de ustedes, no se dejen llevar por los anti-systemd, anti-openrc, anti-nada! Lo que importa realmente es cómo ustedes se desenvuelven en su propio sistema. Obviamente está genial informarse de lo que van a usar, buscar información, tomarse un tiempo para aprender a manejar el init que queremos para que luego por desconocmiento a un manejo correcto no terminemos como varios que leo en grupos de Telegram o en foros diciendo "ésto es una porquería no funciona". ;-) Bueno espero que les haya servido y a continuación les dejo unos links que por ahí les pueda resultar interesantes para leer, mirar toda la polémica, leer diferentes puntos de vista, etc. Links interesantes: Que piensan hacer ustedes? (Encuesta). Opinando de systemd. The Epoch Init System. Are We Removing What defines Arch Linux. Avanzando a Golpe de Actualizaciones de Systemd. Why systemd is winning the init wars and other things aren't. Lennart Poettering Takes To Battling Systemd Myths. Would it be possible for you to cover the pros and cons related to Systemd. Decide which init system to default to in Debian. How do you feel about Opensuse using Systemd? Abrazo de gol!
  2. Es que esa pregunta da para cualquiera, porque dependerá del uso, algunos no usan los virtual host por ejemplo, los cgi, que se yo... Yo normalmente por default, porque lo uso solo local y para probar exploits, practicar, etc. Así que no desactivo tanto los módulos. Enviado desde mi MotoG3 mediante Tapatalk
  3. Anteriormente dejé un mini how-to sobre como instalar zsh y oh my zsh en Archlinux (para los que quieran ver la instalación aquí les dejo el link), en éste caso lo que haré será mostrar la instalación de zsh junto a Oh My Zsh en diferentes distribuciones como ser: * Debian * Ubuntu * Slackware * Void Además dejaré los videos también en el caso que tengan dudas de cada instalación en cada distribución, para que vean como se hace y no tengan ganas de leer. Por las dudas en el caso que quieran ver también la web oficial, requisitos y más información pueden mirarla aquí. Debian y Ubuntu: # apt-get install zsh Slackware: # slackpkg install zsh Void: # xbps-install zsh Instalación de Oh My Zsh: 1 - Descargamos el instalador de oh my zsh de la web del creador $ wget https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh 2 - Le damos permisos de ejecución al instalador (install.sh) $ chmod a+x install.sh 3 - Lo ejecutamos, vamos al directorio dónde lo descargamos y escribimos lo siguiente: $ ./install.sh Comenzará el proceso de clonar del repositorio original, una vez terminado solicitará clave de usuario, terminado el proceso ya tendremos oh my zsh instalado. 4 - Para modificar los themes que tenemos, deberemos editar nuestro .zshrc y en la sección ZSH_THEME modificamos el que está (por defecto "robbyrussell") por el que deseamos, en mi caso elegí "agnoster", también si quieren pueden colocar "Random" para que cada vez que inicien sesión con su usuario tengan un theme diferente. $ nano .zshrc 5 - En el caso que tengan dudas con respecto a lo que realiza el script (install.sh) pueden verlo completo usando un editor de texto o en el mismo github del creador. Desintalación: Si llegamos a la conclusión que no queremos usar más éste script o queremos personalizar zsh de manera manual, podemos eliminarlo también descargando el script de desintalación: 1 - Descargamos el script unistall.sh $ wget https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/uninstall.sh 2 - Le damos permisos de ejecución: $ chmod a+x uninstall.sh 3 - Ahora lo ejecutamos, vamos al directorio dónde lo descargamos y escribimos: $ ./uninstall 4 - Listo! A continuación dejo el video de Instalación y Desintalación en Debian, Slackware y Void respectivamente: Bueno espero que les haya servido éste mini how to. Recuerden por favor compartir ésto para que sigamos creciendo! Abrazo de gol!
  4. Hablar de seguridad en servidores es un tema que da para rato, éste no será el caso, pero si dejaré algunos "tips" de como podemos estar un poco, si, un poco más tranquilos con respecto a la seguridad en nuestro servidor web Apache. 1 - Ocultar la versión de nuestro servidor en Apache y en PHP Cuándo instalamos por defecto apache, éste viene sin modificar muchos parámetros, entonces como consecuencia podemos llegar a encontrar fallos o vulnerabilidades, una de ellas es dar a conocer la versión del servidor ya que damos información precisa de nuestro sistema. Ésto podemos solucionarlo simplmente editando el arhcivo de configuración y agregamos las líneas del ServerSignature dentro del directorio de Apache, normalmente en /etc/httpd/conf/httpd.conf. # nano /etc/httpd/conf/httpd.conf y agregamos al final las siguientes dos líneas: ServerSignature Off ServerTokens Prod Guardamos y salimos. Explico un poco: La línea ServerSignature Off oculta la versión de Apache en cualquier página de error y la línea ServerTokens Prod garantiza que no se muestre dicha información en las cabeceras de respuesta HTTP. Ahora reiniciamos el servicio: # systemctl restart httpd Para la parte de PHP también podemos ocultar la información que se puede mostrar en nuestro servidor, para hacer ésto debemos editar el archivo de configuración de PHP, que se llama php.ini que se encuentra en /etc/php/php.ini. # nano /etc/php/php.ini Y vamos a buscar la líena expose_php = On, ésta se encuentra en la línea número 374 y la vamos a cambiar por expose_php = Off. Guardamos y salimos. Reiniciamos los servicios y vemos el resultado: # systemctl restart httpd Y listo! 2 - Deshabilitar los módulos que no usamos Apache normalmente viene con una configuración de módulos que se podrían decir genéricos para que te funcione todo a la primera (básicamente), entonces una medida de seguridad sería deshabilitar los que no utilizamos. Para mirar cuáles módulos están activos podemos escribir ésta orden: # grep -n LoadModule /etc/httpd/conf/httpd.conf Aquí vamos a ver un listado con todos los módulos que nuestro Apache carga; buscaremos en la lista cuáles son los que no usamos y simplemente en el mismo archivo de configuración vamos a comentarlos colocando un "#" delante de la línea y listo. 3 - Limitar el tamaño de las solicitudes Normalmente algunos ataques pueden comienzar con los viejos y conocidos DOS (Denial Of Service) debido a que permitimos demasiadas solicitudes, en realidad a que permitimos solicitudes de grandes tamaños en nuestro servidor, teniendo en cuenta que Apache no limita ésto, pero podemos evitarlo, simplemente colocando la línea # LimitRequestBody En éste caso, el limite lo podremos según a las necesidades que tengamos, pueden probar hasta encontrar el límite deseado. 4 - Acceso a los directorios fuera del root Darles el privilegio a los intrusos que tengan acceso a directorios fuera de su raíz es dejar una puerta abierta, salvo que realmente necesitemos que Apache acceda a éstos. Para deshabilitar ésta opción tenemos que modificar la entrada de DocumentRoot. Por defecto viene con AllowOverride None, pero podemos agregar algunas más: Order Deny, Allow Deny from all Options None Detallo un poco lo que es None, Deny Allow, Deny from all. None: No permite a los usuarios activar ninguna funcionalidad en éste directorio. Deny, Allow: Son las órdenes que son procesadas respectivamente. Deny from all: Denega el acceso de peticiones de todos los usuarios al directorio "root". En el caso que deseamos dar acceso a ciertas áreas por ejemplo podemos crear un bloque o editar uno dejandolo de ésta manera: Require all granted Require all granted 5 - Los módulos mod_security y mod_evasive Sería importante de contar con éstos módulos en parte, asi que detallo brevemente cada uno: mod_security se podría decir que es un firewall para las web-apps, además de monitorear el tráfico de nuestro server en tiempo real, cosa importante a la hora de evitar ataques por fuerza bruta. mod_evasive intenta prevenir ataques DDOS y vía fuerza bruta, procesando cada petición y analizando su composición por ejemplo: * Si detecta muchas peticiones en poco tiempo. * Si cualquier proceso trata de realizar X cantidad de peticiones. * Si una IP que se encuentra en una lista negra (black list) sigue intentando hacer peticiones. 6 - Deshabilitar los enlaces simbólicos Parece una tontería, por pequeña que sea, siempre puede ser útil a la hora cuidarnos y evitarnos problemas mayores, normalmente en las últimas versiones ya viene habilitada, pero por las dudas se las dejo presente: Options -FollowSymLinks 7 - Revisar los logs! Cosa que en ocaciones cuando recién comenzamos, no somos de mirar ésto, MAL! Es muy importante hacer un seguimiento y estar al día con los archivos de logs que se van generando ya que éstos nos reportan que es lo pasó en X momento. Además nos facilitan a la hora de entender algunos ataques además de que también nos ayudan a futuro para prevenirlos. 8 - Desactivar las opciones para explorar directorios Para evitar que apache muestre, en el caso que no exista un index.html por ejemplo, mostrará los directorios con los archivos, para evitar ésto pondremos dentro de la etiqueta directorio lo siguiente: Options -Indexes 9 - Desactivar todas las opciones Si directamente queremos desactivar todas las opciones antes mencionadas, directamente podemos dejarlo así: Options None 10 - Finalmente, las actualizaciones Normalmente soy de ésas personas que piensa que "lo que funciona bién, no se toca", pero tener actualizado nuestro servidor web considero que es importante a la hora de ahorrarnos un dolor de cabeza, asi que en lo posible tenerlo actualizado sería ideal. Bueno espero que les haya servido y que puedan ponerlo en práctica, recuerden que éstos "tips" son básicos, pero por ahí si recién comienzan en éste mundo de los servidores, les vendrá bién. Datos: Ésto fué configurado en un servidor LAMP en Archlinux32 (En el caso que quieran saber más de ésta distro, aquí les dejo info). En el caso que quieran consultar o compartir sus configuraciones también pueden encontrarnos en el grupo de Telegram de LinuxerOS o comentar aquí. Recuerden en lo posible compartir el blog así seguimos creciendo! Abrazo de gol!
  5. Linux MARATON

    Tendré que madrugar para escuchar la maraton jaja pero lindo evento esperemos que sea, que se repita y que participe más gente de diferentes lugares. :-) Enviado desde mi MotoG3 mediante Tapatalk
  6. Hola!!

    Bienvenido! Enviado desde mi MotoG3 mediante Tapatalk
  7. ¿Qué estás escuchando?

    ja... justo hace unos días con mi hija me decía "papi te quiero mucho" y después bueno estaba mirando videos y en el día del padre veo que estaba ésta canción. Se me puso la piel de gallina! Supongo que algunos lo vieron, pero para los que no, pfff recomiendo prestar atención a la letra ;-)
  8. ¿Qué estás escuchando?

    Hoy pintó alg de Nirvana
  9. Bueno probá, pero recuerda que depende también del funcionamiento de cada dns. Algunos funcionan mejores que otros, será cuestión de que vayas investigando cuál te funciona mejor. :-) Enviado desde mi MotoG3 mediante Tapatalk
  10. Bueno, volvemos con parte de lo mismo mostrado anteriormente, PERO con la condicional de que realmente para instalar éstos paquetes realmente cambiar en diferentes distribuciones como Slackware, Archlinux, Void, etc. Entonces dejo un video tutorial y también ésta entrada para que vean como se configura y se evitan perder tiempo y un dolor de cabeza en todo caso que no deseen investigar mucho. Comencemos! 1 – Para comenzar hay que buscar la orden “dig” que se encuentra en el paquete: dnsutils entonces instalaremos los siguientes paquetes: # apt-get install dnsutils dnscrypt-proxy dnsmasq 2 – Ahora vamos a editar el archivo /etc/resolv.conf y debe quedar así: nameserver 127.0.0.1 3 – Lo que haremos ahora es impedir que se modifique cuando iniciemos el sistema, con ésta órden: # chattr +i /etc/resolv.conf 4 – Siguiendo, editamos el archivo /dnscrypt-proxy.conf que está en /etc/dnscrypt-proxy/ y dejamos éstas líneas: # nano -l /etc/dnscrypt-proxy/dnscrypt-proxy.conf * Recuerden que en la línea ResolverName pueden modificarla por el que quieran. Si quieren mirar que dns pueden agregar, se puede mirar el archivo dnscrypt-resolvers.csv, que se encuentra en el directorio /etc/dnscrypt-proxy. 5 – Pasamos a editar el archivo dnsmasq.conf que está en /etc/ y debemos editar las siguientes líneas: # nano -l /etc/dnsmasq.conf línea 58: no-resolv línea 66: server=127.0.0.1#40 línea 111: listen-address=127.0.0.1 6 – Para finalizar reiniciamos los servicios de la siguiente manera: # systemctl restart dnscrypt-proxy # systemctl restart dnsmasq 7 – Probamos que realmente funcione usando la órden “dig” de ésta manera: # dig linuxforallsite.wordpress.com y volvemos a escribir: # dig linuxforallsite.wordpress.com Veremos el cambio en la línea Query time de 404 msec a Query time de 0 msec. * Tengan en cuenta que el host dónde realizan la “consulta” puede ser el que quieran (siempre y cuando funcione, claro está. Yo usé el de mi blog). En el caso que necesiten mirar que realmente funciona, dejo el video también: https://vid.me/dLPQ Abrazo de gol! Recuerden visitarnos en los grupos de Telegram
  11. ¿Qué estás escuchando?

    Bueno éste domingo (en el cuál me desperté MUY tarde como de costumbre jaja por dormir a las 6AM) ahora son las 15:16hs, puse algo de música y me dieron ganas de escuchar algo de los que los argentinos decimos música "rollinga" Asi que disfruten! Abrazo y buen domingo para tod@s! ;-)
  12. no sé que será normal para vos, pero problemas en instalaciones y ya reportados no me parece "normal". Con respecto a tasksel y mirrors la verdad que puede ser aleatorio, pero lo vi en diferentes equipos de diferentes usuarios. Pero bueno esperemos que mejore con el tiempo. Hace rato que no vi tantos "problemas" en una nueva versión de Debian :-(
  13. La solución que dejaron en launchpad tampoco te sirvió? Enviado desde mi MotoG3 mediante Tapatalk
  14. Creo que se apuraron en largar Debian 9. Por lo menos a mi me sucedió de tener problemas con la instalación (netinstall), también usuarios en el grupo de debian_esp en Telegram tuvieron inconvenientes con los repositorios. Tasksel no funcionó bien. Más allá que en el tercer intento pude instalar bien, ahora está todo OK, pero bueno, me llamó la atención. Les sucedió algo parecido a ustedes? Enviado desde mi MotoG3 mediante Tapatalk
  15. Hola a todos.

    Bienvenido, pasala cool! Enviado desde mi MotoG3 mediante Tapatalk