Bueno, me faltaba este detalle, pero por fin hoy me decidí ya atacarlo y por fin ya tenemos IPv6 en los servidores de nuestrodns.com
así que ya tengo dominado la implementación de ipv6 en los servicios más necesarios para Linux.
Category Archives: Centos
resize2fs en vivo
No lo había probado antes, pero hoy requería de extender el LV de la partición raíz de un server virtual, pues como ya saben ando en el tema de IPv6 y este server de pruebas que tenía se le agotó el espacio para realizar mis experimentos con DNS. Es un server CentOS-6 con lvm, no sé si funcione para CentOS-5
Así que caramba, busqué y me dí cuenta que no tienes que tener desmontada la partición / para extenderla.. simplemente le extendí el LV y luego le hice un :
resize2fs /dev/dsk/root
y me redimensionó perfectamente la raíz. Bueno, por seguridad lo hice en modo 1, pero habría que probar si en otro modo igual funciona.
lighttpd falla cuando activo apc
Bueno, hoy instalé un servidor con lighttpd, y al activarle el apc (php-pecl-apc) el lighttpd no arrancaba, daba un error así:
2012-05-07 14:17:10: (mod_fastcgi.c.1103) the fastcgi-backend /usr/bin/php-cgi failed to start:
2012-05-07 14:17:10: (mod_fastcgi.c.1114) terminated by signal: 11
2012-05-07 14:17:10: (mod_fastcgi.c.1119) to be exact: it segfaulted, crashed, died, … you get the idea.
2012-05-07 14:17:10: (mod_fastcgi.c.1121) If this is PHP, try removing the bytecode caches for now and try again.
2012-05-07 14:17:10: (mod_fastcgi.c.1397) [ERROR]: spawning fcgi failed.
2012-05-07 14:17:10: (server.c.945) Configuration of plugins failed. Going down.
Luego de muuuucho tiempo, en que con ayuda de Paul probamos varias cosas, nada de nada… se me alumbró, el apc escribe hacia /tmp.. y por alguna razón, el directorio /tmp tenía permisos incorrectos, le arreglé los permisos y listo! Todo ok!!
/tmp debe estar: rwxrwxrwt si no tiene estos permisos, fallará al escribir el apc y por tanto no arrancará el lighttpd
Presentación realizada por Ernesto Pérez en FLISOL Riobamba – 2012
Esta breve presentación la realicé para alertar, o ayudar a mejorar la seguridad en los sistemas Linux que corren bajo CentOS (otros linux igual aplica).
El énfasis, si te fijas, está en que hay que entrenar al usuario que trabaja con el equipo, pues lamentablemente hay muchos aspectos tan simples de tratar pero tan continuamente olvidados que se me hace obligado el hablar de esto.
Disfruten aquí del adjunto. Y como siempre, aquí estoy a su disposición por si requieren de una ayudita en flisol.
PD: la perra que aparece en la presentación es July, la perra de mi esposa.
Curiosidades de KVM: KSM
bueno: este tema es buenísimo, me ha encantado de kvm… todo con mesura, pero es una excelente idea.
KSM viene de Kernel Samepage Merging (mezcla de las mismas páginas del kernel).
La idea es que cuando virtualizamos, muy posiblemente las máquinas virtuales que corremos, corren bajo el mismo sistema operativo, por lo tanto la posibilidad de que las memoria de estas máquinas estén manteniendo una copia similar de ciertas páginas de memoria es altísima.
Dicho de otra forma: supongamos que tenemos dos máquinas virtuales: centos1 y centos2, ambos corriendo centos-6.2 por ejemplo. La posibilidad de que ciertas partes de memoria de la máquina “centos1” tengan la misma información que la máquina “centos2” es alta, porque posiblemente corren el mismo kernel, quizá procesos similares (mysql, dovecot, sendmail, postfix, apache, etc)..
¿Qué ventajas nos permite esto? Correr varias máquinas virtuales aprovechando al máximo la memoria, pues no se repetirá la misma información que se almacena en la memoria, sino que solamente se mantiene una copia.
Hoy realicé una pequeña prueba, que fue crear 10 máquinas virtuales de CentOS-6, clonándolas por supuesto para hacer el proceso rápido, y luego arrancarlas.
Primero verifiqué que mi kernel del hospedero tuviera kvm activado (el de los invitados deberían tenerle también):
egrep -i ksm /boot/config-2.6.32-220.4.1.el6.x86_64
CONFIG_KSM=y
Entonces a cada máquina virtual le asigné 900MB de RAM, por probar, podría haber usado otro valor. Y luego las arranqué.
Mi sistema hospedero tiene 3GB de RAM solamente, no más. En Xen para CentOS-5 no hubiera podido usar más que 3GB para asignar por máquina por ejemplo hubiera podido correr 2 máquinas de 1gb cada uno y una de 512mb (porque al hospedero en xen hay que dejarle un poco de memoria).
Ahora, en kvm, acabo de arrancar las 10 máquinas virtuales, cada una de 900MB de RAM. Esto sumaría 900MB*10maquinas= 9GB verdad? Pues las máquinas arrancadas consumen menos de 2GB en total!!! No lo crees? mira:
Esto fue antes de arrancar todas las máquinas:
[root@dom0 ~]# free -m
total used free shared buffers cached
Mem: 2982 2908 74 0 2584 32
-/+ buffers/cache: 290 2691
Swap: 511 6 505
En suma, el hospedero está usando aproximadamente 290MB de ram nada más.
Esto es luego de arrancadas las 10 máquinas de 900MB de RAM cada una!!:
[root@dom0 ~]# free -m
total used free shared buffers cached
Mem: 2982 2261 720 0 0 21
-/+ buffers/cache: 2239 742
Swap: 511 64 447
En suma, el hospedero ahora usa 2.2G
por tanto el incremento en el uso de la ram entre el primer escenario (sin máquinas virtuales arrancadas) y el segundo (con las 10 máquinas virtuales arrancadas) es de menos de 2GB.
si miras dentro de una máquina virtual, esta reporta que está usando 900MB.. no menos…
una forma de verificar que el ksm está en efecto haciendo su función es ver la cantidad de páginas ksmeadas:
[root@dom0 ~]# cat /sys/kernel/mm/ksm/pages_sharing
362484
Ahi está, 362mil484 páginas ksmeadas.
Estoy impresionado, pero hay que ser cauteloso, por qué tan bajo consumo? Porque todas las máquinas son iguales y están haciendo exactamente las mismas funciones, en este caso todas las máquinas están simplemente encendidas, realizando NADA .. esperando a que yo me conecte por ssh y nada más.
No hay que ser abusador como en este escenario en el cual arranqué tantas máquinas, leí en algún lugar, luego lo documento, que redhat sugería no se sobrevendiera la memoria por más de un 10% porque a la final las máquinas pueden comenzar a realizar labores diversas y no se pueda hacer uso del KSM al no haber muchas páginas similares.
Aquí las 10 máquinas corriendo:
Un comentario adicional, ahora acabo de verificar la ram y no supera los 875mb de uso!
[root@dom0 ~]# free -m
total used free shared buffers cached
Mem: 2982 949 2032 0 15 58
-/+ buffers/cache: 875 2106
Swap: 511 61 450
No lo sé, pero la idea es que puede decrecer, pero fíjate.. puede crecer también su uso, así que cautela ok?
Activarlo es medio raro. Yo realmente lo que hago es editar esta variable:
vi /etc/sysconfig/ksm
KSM_MAX_KERNEL_PAGES=0
luego reinicio el servicio ksm y en teoría debe funcionar.
Instalando correctamente dovecot en CentOS-6
Ya me ha sucedido varias veces y ya voy a escribir un peque howto sobre esto.
Resulta que en CentOS-6 se ha hecho un poquito más complejo el instlar correctamente el dovecot, anteriormente era simplemente instalarle y arrancar el servicio y ya funcionaba, ahora igualmente debemos hacer:
yum install dovecot
sin embargo ahora me he topado con dos curiosidades que hacen que no solamente debamos instalarle y arrancarls… ok podrían tomarse como características si le vemos así:
La primera es que ya no acepta autenticación en texto claro. Esto definitivamente es una ventaja, una mejora.. supuestamente todo lector de correos que se conecte a través de POP3 o IMAP4 debe usar algún tipo de sistema que no envíe las claves en texto claro. Lamentablemente muchos sistemas de correos actualmente no tienen o no es trivial el que usen esos métodos para encriptar el envío de información.
Repito, es positivísimo y esto debe convertirse en algo natural, estándar.. sin embargo mucha gente al momento se confunde por esto. Una variante es investigar y lograr la autenticación encriptada, la otra, facilista es cierto!, es pedirle que siga aceptando autenticación en texto claro.
Para volver a poner autenticación en texto claro, una vez instalado dovecot como hicimos arriba, simplemente editamos este archivo:
/etc/dovecot/conf.d/10-auth.conf
y descomentamos una línea que está casi arriba arriba y le ponemos con no, así:
disable_plaintext_auth = no
y listo, si reiniciáramos el dovecot, ya estaría aceptando autenticación en texto claro.
Pero aguanta, no reinicies todavía, ahora viene lo más engorroso. Luego que me pongo a verificar, me daba error al autenticar en POP3, algo así salía:
Oct 22 14:01:10 curso dovecot: pop3(prueba): Error: user prueba: Initialization failed: mail_location not set and autodetection failed: Mail storage autodetection failed with home=/home/pruebaMolesto, muy molestoso el encontrar la solución, inmediatamente me puse a cambiar variables, quitar y poner y me pasé, literalmente, una hora con el mismo problema.
En resumen es que dovecot trata de detectar el mail_location automáticamente, el directorio donde estarán los mails de los buzones de IMAP4, pero falla miserablemente… lo único que hay que hacer es no dejarle detección automática sino definirle directamente el mail_location, esto se hace editando:
/etc/dovecot/conf.d/10-mail.conf
entonces descomento una línea que dice así (no dejen espacios delante del comentario:
mail_location = mbox:~/mail:INBOX=/var/mail/%u
Esta línea está por la segunda página, y está comentada, repito: quítale los espacios de alante, la m de mail_location debe quedar en la primera columna.
También en el mismo archivo descomento y cambio las dos siguientes líneas:
mail_privileged_group = mail mail_access_group = mail
Y reinicio dovecot! Listo!
Ahora viene un tema simple, al conectarte nuevamente con un usuario, la primera vez que lo hagas fallará nuevamente, pero sólo la primera vez, te conectas de nuevo y ya no falla.
Esto lo veo feo, pero así es como está configurado ahora.. falla, pero crea el directorio ~/mail y ya no vuelve a fallar.
Si sigues este howto al pie de la letra, ya te funcionará el dovecot con esta excepción del fallo a la primera autenticación.
Cualquier duda, me avisas a ver cómo se te puede ayudar.
Ayúdame, pero de pana
24 de Diciembre de un año cualquiera, los niños y la esposa montados en el carro, listos para salir para Ambato a pasar el fin de año… nadie compra NADA esos días.. de repente: Riinnng..
Panita, te acuerdas de mí? Bueno recuerda que estoy trabajando para X dependencia gubernamental, te hicimos caso e instalamos virtualización y ahora una máquina virtual no quiere arrancar
Por qué, por qué te tratan de guiar aun problema cuando no es tal? Por qué simplemente no dicen: no arranca un servidor… por qué la insinuación de que es por culpa de la máquina virtual?
Por supuesto, en el carro se armó un patatús, yo no bajaba… y ellos allá abajo dando brincos en el carro.. nada, suban… trabajo es trabajo.. aquello no arrancaba en efecto, pero bueno, es lo bueno de las máquinas virtuales, una máquina que no arranca, le puedes “abrir el disco” así llamo al hecho de poder acceder a las particiones desde el sistema hospedero.. y mirar dentro.
Nada dentro de ese disco estaba todo ok, se veían los directorios de la raíz, /etc /usr /home /var.. todo todo se veía!
Mirando bien, aquella cosa al arrancar decía que no encontraba archivos básicos! Pero cómo era eso? Todo por culpa de esa virtualización decían estos amigos. Y repentinamente.. cuando miro dentro de /usr habían directorios pero no habían archivos ! Dentro de los directorios no había nada.. en resumen, mirando dentro de cualquier directorio todo estaba vacío, era como una casa en la que había pasado una tropa de ladrones y se hubieran tomado el tiempo para sacar hasta los clavos.
Les digo: oigan, esto no es virtualización, aquí han hackeado este servidor! Todo está borrado!! Hasta que me confiesan: mira, un compañero del trabajo quería borrar todo dentro de un directorio y puso:
rm -f /*/*
Cómo? Todavía no te sé explicar, no sé qué gusano pasaba por dentro de la mente del REkaballo (este es otro,era un REkaballo) que planificó ese comando! en resumen, borró todos los archivos dentro de los directorios pero no los directorios. Este comando no lo repitas en ningún lugar, no es para que lo uses, es para darte una idea de lo que puede hacer la ignorancia cuando es atrevida…
A la final.. buena platica por navidad… y gracias, pero tienen que reinstalar, han cagado el sistema.. hasta luego me voy que me matan los niños!
VPN roadwarrior usando dd-wrt
Bueno, un cliente lo pidió, así que me tocó.
dd-wrt es un firmware que sirve para una enorme variedad de routers inalámbricos de bajo costo que pululan en ebay y demás.
a veces es necesario establecer una conexión de VPN entre una red local que queda detrás de este tipo de router y un cliente externo. Me gusta mucho openvpn y he visto que dd-wrt lo ofrece para ciertos routers (con mucha RAM y almacenamiento), en mi caso compré hace unos años, de casualidad un Buffalo WHR-HP-G54 que permite que le flashees con este sistema.
Le tengo puesto el último firmware de dd-wrt, el DD-WRT v24-sp2 (08/07/10) vpn – build 14896 , fíjate la palabrita “vpn” en el nombre, este es un firmware muy grande, pero que cabe en este router al 100%.
Siguiendo los pasos que publiqué hace muchos años en EcuaLUG generé el ca.crt, server.key, server.crt y el dh1024.pem
Estos archivos los generé en un servidor Linux mío.. cualquiera.. que tuviera openvpn instalado. Y los contenidos de estos archivos los puse en el panel de control de router con dd-wrt donde dice Services -> VPN, ahi activé “Start OpenVPN Daemon”, mira las siguientes imágenes y lee debajo qué puse en cada caso:
En
- CA cert, copié los contenidos que generé del ca.crt
- Certificate Revoke List: no copié nada
- Public Client Cert: copié los contenidos de server.crt
- Private Client key: copié los contenidos de server.key
- DH PEM: copié los contenidos de dh1024.pem
- OpenVPN confíg puse los contenidos que más abajo verás.
- OpenVPN TLS Auth : no puse nada.
En el config puse algo así, solamente tienes que cambiar la primera línea y poner la red interna que uses, en mi caso la red que está dentro de mi router dd-wrt es 192.168.8.0/24 (255.255.255.0=/24)
push "route 192.168.8.0 255.255.255.0"
server 10.10.0.0 255.255.255.0 dev tun0
proto tcp-server
port 1194
keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem management localhost 5001
comp-lzo
Y listo, apliqué los cambios.
ahora tuve que abrir el puerto 1194 en tcp, normalmente se usa udp pero mi proveedor de internet parece bloquearlo por lo que me cambié a tcp y a mi me funcionó.
Para abrir el firewall vete a “Administration” -> “Commands”
ahi escribes sólo dos líneas:
iptables -I INPUT 1 -p tcp --dport 1194 -j ACCEPT iptables -I FORWARD 1 --source 10.10.0.0/24 -j ACCEPT
Esto le indica que abra el puerto 1194 en tcp y que permita conexiones que provengan del tunnel (10.10.0.0/24).
Aprietas el botón que dice: “Save Firewall”
Y listo! Ya tenía activado el servidor de dd-wrt como un servidor de openvpn. Por supuesto seguí el tutorial de EcuaLug para la parte del cliente, normalito, como dice el tutorial para el cliente.
Y ya tenemos IPv6!
Esto acabamos de publicar en el Blog de NuestroServer.com
Bueno, desde hace mucho tiempo tenemos activo el servicio de IPv6 para nuestros clientes dedicados y dedicados virtuales. Pero increíblemente no lo habíamos implementado en nuestro propio servicio. En casa de herrero cuchillo de palo.
Pero eso se arregló hoy, desde hoy en adelante tenemos IPv6 activa en nuestro servicio, si tienes ipv6 activa en tu red local puedes de momento acceder a nuestro servicio via ipv6 entrando a: http://ipv6.nuestroserver.com o a http://www.ipv6.nuestroserver.com o a www6.nuestroserver.com lo mismo se podrá hacer con nuestros otros sitios web. Si no tienes IPv6 activa en tu red local, preocúpate y llama ya a tu proveedor de internet.
Hemos de notar que somos el primer proveedor en el país en ofrecer el servicio de IPv6 para nuestros clientes. Y no es poca cosa… las IPv4 ya se agotaron y en pocos meses se comenzará a notar la escasez de ellas.. por lo que es bueno prevenir, por responsabilidad con los clientes.
A mediano plazo comenzaremos también a ofrecer este servicio a los clientes compartidos.
Si deseas obtener tu propia IPv6 con nosotros, mira nuestros planes de servidores dedicados virtuales
Como invocar correctamente al su
¿Cómo se debe usar? su ó su – ?
¿Este signo de menos (-) después del su tiene importancia? Acaso no funcionan igual?
La realidad es que sí hay diferencias y muy apreciables. Yo recomiendo usar siempre su – con el signo de – detrás.
Este signito de menos te importa el perfil del usuario al que estás accediendo (normalmente root).
Es decir, si eres el usuario eperez y ejecutas su (sin el -) entonces serás root pero con el perfil de eperez.
si eres el usuario eperez y ejecutas su – entonces serás enteramente root.
Pero espera: ¿qué es esto del perfil?
Es un archivo que está en dos lugares, en /etc/profile está el perfil general del sistema (que aplica a todos) y en ~/.bash_profile (en el directorio del usuario) está el perfil particular de un usuario que se incorpora después de haberse importado /etc/profile
Qué va dentro de este perfil? Sobre todas las cosas y a lo único que me referiré es que dentro del perfil de un usuario va una variable super importantísima llamada: PATH
PATH es una variable que contiene el camino de búsqueda para cuando ejecutas un comando. Por ejemplo si no existiera el PATH o estuviera en blanco, para listar un archivo deberías ejecutar: /bin/ls (con el camino completo).
Ahora, como tenemos el PATH, podemos ejecutar simplemente “ls” y el sistema buscará en TODO su PATH por el comando ls.. en orden.
Por ejemplo veamos el PATH de mi usuario eperez:
echo $PATH
/usr/lib/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/home/eperez/bin
Bien, mi PATH dice que hay que buscar en todos estos directorios, en ese orden (de izquierda a derecha), primero /usr/lib/qt-3.3/bin, después en /usr/local/bin, etc.. así que cuando ejecuté simplemente “ls” mi sistema seguro lo encontró en el 4to PATH definido (/bin)
Por supuesto si hubiera un comando ls en /usr/local/bin por ejemplo, este hubiera sido el que se hubiera ejecutado, pues siempre se ejecuta uno, el primero que aparezca en el orden en que está el PATH.
Hasta aqui todo ok?
Bien, ahora tenemos aqui la primera razón por la cual debemos usar su – y es que el PATH del usuario root tiene caminos adicionales, mira:
/usr/lib/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
no ves nada diferente? pues aparecen /sbin, /usr/sbin y /usr/local/sbin que son directorios donde se encuentran los binarios que solamente root puede ejecutar.
Si pusiera su en vez de su -, entonces persistiría el perfil (el PATH) del usuario eperez, que no tiene los “sbin”.. y por tanto cuando escribas por ejemplo: useradd prueba que es un comando que está en /usr/sbin/useradd el sistema te dará un error diciendo que no existe.. el comando, y esto es porque /usr/sbin no está en el PATH.
Ahora claro, hay dos posibles soluciones:
1- pongo el comando completo: /usr/sbin/useradd sin embargo si tuvieras que ejecutar todos los días decenas de veces comandos dentro de estos directorios, sería muy lento y aburrido, y recuerda que linux es para disfrutarle
2- algunas distribuciones de linux están incluyendo los directorios “sbin” ya en cualquier usuario de forma tal que sea o no root, siempre lo tendrá.
ahhh.. entonces mejor nos cambiamos de distro y ya dirán algunos vivazos que quieren ahorrarse el poner el insignificante signo de –
Ahora veremos la segunda y más importante razón de por qué usar su – con su signo de -:
¿Qué tal si yo altero el PATH como un usuario normal.. adiciono un nuevo camino propio mío delante de todos los PATH y entonces te llamo a tí, sabiendo que usas simplemente su y no su – ?
¿Qué pasará? que como no pones el signo de -, el PATH mío persistirá, entonces yo que soy un malintencionado, haré un programa que pondré en ese camino que se hará pasar por el original y te hará daño.
No lo crees? Mira aqui:
Aqui lo que hice fue prinero crear un archivo llamado “ls” dentro de mi propio directorio /home/eperez, dentro de este archivo simplemente invoco a useradd para agregar un usuario con uid 0,después a chpass para ponerle una clave al usuario, entonces par confundir a mi víctima le invoco al verdadero ls (fíjate que le pongo con el camino completo) y le paso cualquier parámetro que me hayan pasado en mi script falseta.
Entonces le doy derecho de ejecución.
En este instante, chequeo en .bash_profile que en el PATH, de primerito exista el directorio llamado “.”, este directorio es “este”, “donde estoy parado actualmente”.
Salgo y entro de la sesión y valido que ya tenga el directorio . en el PATH.
Bien, ahora viene la parte de ingeniería social, llamo a mi administrador y le hago una historia que le obligará a convertirse con su en root, el pobre sysadmin lo hace con muchas ganas de ayudar, desde mi usuario, pero no usa el -, por lo que el PATH permanecerá el mío!! Bieeeen! entonces cuando escriba “ls” se ejecutará mi ls y terminará creando inconscientemente un usuario con derechos de root.
Claro, esta historia tiene muchas aristas (pude haber simulado el mismo comando su)
Ahora te pido que pruebes toda la demostración anterior pero usando su – ahi si te fijas, se importará el PATH del usuario root y por tanto no permanecerá el PATH modificado del usuario normal. Para evitar que me simulen el su, podrías usar el camino completo: /bin/su
Lo mejor mejor, es no usar el su sino en tu propio usuario y siempre validar que no tengas binarios bajados por error o con intención por tí o por terceros incluso en tu propio directorio. Y sobre todas las cosas: no permitas nunca que te pongas o tengas al directorio . en tu PATH