Configurar un servidor para que tome la hora de un servidor NTP

Bueno aqui una pequeña entrada para configurar el servicio de NTP (network time protocol)
y tener un server CLIENTE sincronizado con la hora de otro, o vulgarmente conocido como "peer"

• verificamos e instalamos el paquete ntp

• una vez instalado editamos primero /etc/ntp.conf y agregamos la linea 

             peer my.server.ntp.ip es decir la ip y comentamos si no es necesario los demás servidores en el archivo, excepto lo siguiente ya que esto es para que tome el reloj local a menos que lo queramos inactivo:
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

• posteriormente habilitamos y arrancamos el servicio, para red hat 7 y 8

systemctl start ntpd
systemctl enable ntpd

• Sincronizamos nuestro servidor:  ntpdate -u my.ntp.server.ip  

Finalmente podemos ver el resultado y sincronizacion o desfase del horario con el siguiente comando
ntpq -pn
     remote                             refid      st t when poll reach   delay   offset  jitter
==============================================================================
*my.ntp.server.ip     xxx.xx.xxx.xxx   2 u  509  512  377    0.259  -134.83  83.376

si la ip esta listada y tiene un simbolo de asterisco ( * ) quiere decir que nuestro servidor esta tomando la hora desde ese servidor, podemos tambien validar la hora actual del servidor con
date;clock para ver la hora del server.

ntpstat // estadisticas de sincronizacion

finalmente si tenemos el firewall activo, ejecutamos:
firewal-cmd --permanent --add-service ntp
firewall-cmd --reload
systemctl restart ntpd

probado en red hat 6 y 7

IP tables o kernel routing tables

Bueno esta no es una entrada muy extensa y va al grano
las tablas de routeo o rutas estaticas nos sirven para direccionar el trafico de una ip en especifico hacia una interface y/o ip en especial, es decir podemos forzar todo el trafico hacia una interface de red/tarjeta a una ip o de una ip a un gateway aqui los comandos:

#### Route IP Traffic and Create Static Routes ####
ver las tablas de routeo:
ip route list o bien con route o bien con netstat -nr personalmente prefierlo el ultimo ya que suele mostrar las tablas por ip y de momento es lo que mas utilizo o /sbin/route -n




Para agregar una nueva tabla o borrarla utilizamos los siguientes comandos, para les versiones mas "nuevas" utilizaremos:
agregar tablas de routeo: ip route add 216.58.217.0/24 via 10.208.192.1 (//gw) dev eth1
o bien en versiones mas antiguas (red hat 5 por ejemplo) : route add default gw 192.168.1.254 eth0
 
borrar tablas de routeo: ip route del 216.58.217.0/24 via 10.208.192.1 (//gw) dev eth1
de igual forma en versiones mas antiguas solo subtituimos el route add por route del y el resto de la secuencia de la ruta que deseamos eliminar

ahora bien los comandos anteriormente descritos agregan una ruta de forma no permanente, para hacer persistente las tablas de routeo editamos el siguiente archivo
vim /etc/sysconfig/static-routes
y agregamos la siguiente linea donde agregaremos toda la ruta en este caso
               IP                                 MASCARA               GATEWAY          INTERFACE
any net 173.194.205.0 netmask 255.255.255.0 gw 162.242.253.1 dev eth0

lo anterior descrito funciona bien para red hat 6 y 7 no lo eh probado en versiones anteriores

configurar proxy variables globales para linux y yum

Bueno esta es una entrada corta, resulta bastante útil configurar un reverse proxy, en este caso me toco configurar algunos servidores por proxy y aunque es algo "viejo" aun se utiliza.
basicamente se  agregan las siguientes variables a: /etc/profile

http_proxy=http://ip o url :puerto
https_proxy=http://ip o url :puerto
export http_proxy
export https_proxy

esto si queremos que el proxy sea global y para todos los usuarios, pero si lo queremos para solo 1 usuario en especifico, en ese caso agregaremos las mismas variables pero al .bash_profile del usuario al que queremos que todo su trafico pase por el proxy.

para configurar yum y que utilize HTTP / HTTPS proxy hay que editar /etc/yum.conf  y agregamos la siguiente linea

proxy=http://ip o url :puerto
ejecutamos yum clean all para limpiar el cache

ahora bien si el proxy requiere password  editamos el siguente archivo /etc/sysconfig/rhn/up2date:

enableProxy=1
enableProxyAuth=1
proxyPassword=UserPassword
proxyUser=UserName
httpProxy=http://ip o url :puerto

Probado en :
red hat 5, 6 y 7

eastern egg repos de google cloud para linux

Link para ingresar a los repos de cloud de google

https://packages.cloud.google.com/yum/repos/

aqui podemos obtener kubernetes o google monitor

por ultimo un link para hechar a andar google kubernetes y orquestar clusters

install kubernetes 1.7 en centos7 y rhel7
installing kubernetes 1.8.1 on centos 7

Por que me no me gustan los productos apple en especial el iphone

Esta es una entrada de un hater apple el que sea poco susceptible a críticas o fanboy de la manzana puede ir cerrando con gusto este blog.

Me voy a tomar lo molestia de explicar que es lo que no me gusta de dicha empresa y por qué ese "odio" si así se le puede llamar al repudio que le tengo a los smartphones de la manzana así como a varios otros de sus productos.

1. Plataforma cerrada: si aunque ya han liberado mucho del código sigue siendo una plataforma muy restrictiva tanto OSX como IOS 10, 9, y etc... tiende a imponer comportamientos, soluciones o restricciones tanto para "bien" como para mal.
2. Marketing extremadamente falso y agresivo: en base a un marketing brutal y mensajes subliminales la empresa de la manzana tiende a "vender" un "status", además de que casi siempre exagera sobre manera sus slogans, y vende un producto sobre calificado.
3. Precios exorbitantes: me refiero a que no lo valen sus productos, cierto es que no son malos tampoco son los mejores pero si los vende como si fueran los mejores y la tasa de sus precios por lo menos en México si son brutalmente elevados entre el precio normal y los impuestos.
4. Poca compatibilidad: al igual que Linux se batalla con la compatibilidad de ciertas aplicaciones y dispositivos, sin embargo el hardware y software restrictivos de la manzana suele hacer mucho más difícil la convivencia con  otros sistemas operativos u o partes de hardware restringiendo el uso a solo sus productos en la mayoría de los casos cuando estos pueden no cubrir una necesidad o verse limitados, muchos usuarios que conozco acaban tristemente instalando otra cosa (parallels, vmware etc...) o alguna herramienta de virtualización para poner las ventanas :-s.

en pocas palabras me da coraje que le vean la cara a la gente, que le vendan espejos y que la gente todavía los compre pensando en un "status" o cayendo en la mercadotecnia absurda.

me a tocado ver personas muy cercanas a mi sufrir con dichos sistemas al no poder realizar sus tareas, ver que venden el dichoso smartphone como lo mejor  y resulta ser tecnología, desfasada en muchos casos, o incompatible, de tal modo que si no tienes los demás productos de la marca resulta ser una experiencia frustrante o poco útil al no poder explotar todo el potencial de la "inversión", no es así en la mayoría de los casos de los usuarios expertos o avanzados.

finalmente agregó el comparativo de un S7 edge vs un Iphone 7 juzguen ustedes para mi es muy claro que el Galaxy destroza en características. lol 

Phonearena compare

Crear una conexión sin passwords entre servidores utilizando ssh/sftp

Saludos y bueno y que es sftp (secure file transfer protocol)
es un protocolo para envio de archivos basado en ssh (secure shell), y bueno y para que demonios sirve?, es en realidad para transferir archivos entre servidores o bien computadoras usando un método seguro donde la información va encriptada por ssh.

Hasta aquí todo bien y así debe ser, que pasa cuando tenemos uno o más servidores y queremos transferir un archivo usando ssh ?

Bueno aquí va la receta de la casa para utilizar ssh (lo que yo uso para realizar conexiones entre servidores)

1. server origen y/o usuario origen (si, puede ser un windows aunque no entraré mucho en el tema y además está samba ne vez de usar ssh para transferir)
2. server destino y/o path destino
3. el usuario origen y el usuario destino
4. se puede usar un gestor de transferencias como filezilla o winscp o bien en este caso usaremos la poderosa terminal :-)

Ahora bien sftp tiene varios procesos que puede hacer, 2 de los más sencillos de entender y usuales es PUT y GET.

• Put se encarga de "empujar" o subir una archivo o path que le indiquemos 

• Get se encarga de "traer"o bajar del servidor un determinado archivo o bien path.

Requisitos de linux a linux o linux a unix like
Requisitos como ya mencione algunos:
1.- tener el usuario origen (el que va a conectarse hacia el otro servidor)
2.- tener el usuario destino
3.- contar con el password del usuario destino * este es opcional  nos facilita mucho las cosas

Ejecución:
1.- con el usuario origen el que queremos que envíe el archivo) ejecutamos el siguiente comando ( esto va a generar la llave de tipo rsa, recuerda que hay varios tipos de algoritmos; rsa suele ser el más común no por eso menos seguro)

ssh-keygen o ssh-keygen -t rsa

El comando anterior creará las llaves de autenticación en su home directory del usuario en:


~/.ssh/  (donde el tilde significa /home/miusuario)

NOTA:en este paso puede que te solicite crear un passphrase
para que sea una conexión totalmente sin password solo tecleamos enter sin poner nada en este campo, a menos que quieras especificar uno en cuyo caso recomiendo guardes bien esta contraseña ya que te será solicitada cada vez que te quieras conectar.

2.-el siguiente paso es copiar la llave publica al usuario destino en el servidor destino para eso tenemos un par de formas para realizarlo podemos utilizar el comando ssh-copy-id o enviamos/copiamos la llave pública del usuario origen al usuario receptor o destino en el server destino con: 

ssh-copy-id -i ~/.ssh/id_rsa.pub server_destino


o bien hay que entrar al servidor destino/remoto siendo el usuario origen (el que compartió la llave)

ssh usuariodestino@serverdestino o sftp usuariodestino@serverdestino

4.- Colocar la llave pública en el otro server/usuario en el archivo authorized_keys con el siguiente formato:
ssh-rsa llave user@(ip|hostname)
yo te recomiendo realizarlo con: 
cat llave_origen.pub >> authorized_keys
el archivo authorized_keys se ubicara en ~/.ssh/


Los errores más comunes :
-Revisar que el usuario destino y origen no estén bloqueados
-Si este procedimiento de arriba no funciona, lo mejor es buscar el sshd_config del servidor
de SSH y añadir las siguientes líneas, o descomentar las:

RSAAuthentication yes       (usado para checar el knownhost)
PubkeyAuthentication yes

- Revisar que el usuario origen y destino no estén bloqueados con passwd -s (solaris) passwd -S (linux)

-Revisar el tamaño de las llaves que correspondan con las proporcionadas ya que al copiar y pegar puede ser 
que se haya omitido algún caracter, vigilar el mismo numero de lineas la llave solo mide el equivalente a una sola línea de ahí que recomiendo que se utilice el "cat" para concatenar correctamente la llave al final del archivo authorized_keys en una sola línea.

Revisar
------------------------Permisos en los directorios y archivos //muy importante el home
example
user: juanito
HOME:
drwxr------  4 juanito staff 512 jun 5 09:58 /home/501924789

drwx------ 2 juanito staff 512 jun 5 09:58 /home/juanito/.ssh

-rw-r--r-- 2 juanito staff 512 jun 5 09:58 /home/juanito/.ssh/authorized_keys


En algunas ocasiones en linux pueden interferir los contextos de SElinux para esos casos hay que revisar dichos permisos

para revisar los contextos se utiliza:
ls -laZ
el siguiente ejemplo es ERRONEO por tener en el contexto de SELinux como home_ROOT_T cuando deberia tener ssh_home_t
rw-------. juanito staff unconfined_u:object_r:home_root_t:s0 authorized_keys

para cambiar o restaurar los permisos se ejecuta el siguiente comando
restorecon -r -vv ~juanito/.ssh/ donde juanito... es el home del usuario

los permisos deberían de mostrar una forma como la enlistada más abajo  para todos los archivos

[root@server.chipocludo.ssh]# ls -laZ ~juanito/.ssh/
drwx------. juanito staff unconfined_u:object_r:ssh_home_t:s0 .
drwx------. juanito staff system_u:object_r:home_root_t:s0 ..
-rw-------. juanito staff unconfined_u:object_r:ssh_home_t:s0 authorized_keys
-rw-r--r--. juanito staff unconfined_u:object_r:ssh_home_t:s0 known_hosts


Configurar 2 o más llaves simultáneas con un mismo usuario 

Aquí podremos configurar 2 llaves distintas para el mismo usuario es decir nuestro usuario origen va a poder utilizar llaves distintas para autenticarse según el destino que sea necesario o el usuario destino al crear un archivo llamado config en la carpeta ~/.ssh/
también nos da la posibilidad de utilizar llaves con diferentes cifrados es decir tener una con 1024 y otra cifrada con 2048 u otra más pero con cifrado DSA.

1.-configura que una llave este funcional es decir los pasos de arriba para RSA
2.- ya con la llave funcionando puedes moverla a una carpeta, hay que vigilar muy bien los permisos
3.- se crea la segunda llave con los mismos pasos y a esta le vamos a poner otro nombre de archivo ejemplo: id_rsa2_t
   -- nota es posible que sea necesario ejecutar :

      ssh-add id_rsa e ingresar el passphrase que utilizaste si es que tenias alguno.
4.- de igual forma se mueve a otra carpeta la segunda llave para mantener ordenado/separadas las llaves generadas

5.- creamos  el archivo config, de igual manera revisar los permisos ver el ejemplo más abajo:
touch config
6.- y agregamos la siguientes líneas dentro de config con nuestro editor de texto preferido
-bash-4.1$ vim config
Host server.chipocludo // esta linea indica el nombre del host
        User  test_ssh // el usuario al que nos vamos a conectar
        Hostname server.chipocludo // el hostname destino
        PreferredAuthentications publickey // el tipo de autenticación
        IdentityFile ~juanito/.ssh/primerallave/id_rsa //la linea mas importante aquí se indica la ruta del archivo con el que nos vamos a identificar. 

Host server.chipocludo
        User  test_ssh2
        Hostname server.chipocludo
        PreferredAuthentications publickey
        IdentityFile ~juanito/.ssh/segundallave/id_rsa2_t //la linea mas importante aquí se indica la ruta del archivo con el que nos vamos a identificar pero para el servidor 2 o el usuario dos

vamos a ver como quedo la primera llave  en la carpeta 1
-bash-4.1$ cd primerallave
-bash-4.1$ ls -ltr   -------------> en esta parte ojo con los permisos y el selinux en linux
total 8
-rw-------. 1 juanito staff  407 Feb 26 14:19 id_rsa.pub
-rw-------. 1 juanito staff  679 Feb 26 14:19 id_rsa
-bash-4.1$ cd ..
-bash-4.1$ pwd // mas o menos asi queda tu carpeta
/home/juanito/.ssh
-bash-4.1$ ls -ltr
total 20
drwxr-xr-x. 2 juanito staff 4096 Feb 26 14:27 segundallave
drwxr-xr-x. 2 juanito staff 4096 Feb 26 14:27 primerallave
-rwxr-xr-x. 1 juanito staff  432 Feb 26 14:46 known_hosts
-rw-r--r--. 1 juanito staff  406 Feb 26 15:12 authorized_keys
-rwxr-xr-x. 1 juanito staff  392 Feb 26 15:28 config ----> este es el archivo


otro ejemplo utilizando el config file
Host github.com
User git
Hostname github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/git/id_rsa
Host fedoraproject.org
Hostname fedoraproject.org
PreferredAuthentications publickey
IdentityFile ~/.ssh/fedoraproject/id_rsa
Host fedorapeople.org
Hostname fedorapeople.org
PreferredAuthentications publickey
IdentityFile ~/.ssh/fedoraproject/id_rsa

ejemplo: 3 
Host *.dominio.chipocludo.com
        PreferredAuthentications publickey
        IdentityFile ~juanito/.ssh/basekey/id_rsa
Host sufruta.mm.com
        User aldo
        Hostname sufruta.mm.com

        PreferredAuthentications publickey

referencia: http://www.robotgoblin.co.uk/blog/2012/07/24/managing-multiple-ssh-keys/

Activar el modo debug en bash

Yo se me van a amar aquellos que apenas empiezan como yo en el mundillo de bash y la programación en shell script

veamos cuando la opción x en bash es agregada, bash imprimirá cada comando que ejecutará antes de ejecutarlo en la salida de standard error. eso después de aplicar cualquier expansión . como resultado  tu podras ver lo que ocurre. hay que poner especial atención en el entrecomillado. Bash utiliza las comillas para presentar exactamente las cadenas que son pasadas al script como argumentos únicos 

Básicamente hay tres formas de activar el modo debug

• Correr el script con bash -x:

  $ bash -x ./scriptsito_del_mal

• Cambiar el shebang (header):

  #!/bin/bash -x
  [.. script ..]

• O:

  #!/usr/bin/env bash
  set -x

• O agregar set -x agregar -.x o +x en bloques específicos de tu codigo para prender o apagar el modo debug y solo afectar a esa parte de tu código:

  #!/usr/bin/env bash
  [..aquí no importa este código..]
  set -x
  [..aquí había problemas activar el modo debug..]
  set +x
  [..aqui ya no esta activo el modo debug ..]

la salida del modo debug usualmente se despliega en stderr,lo que implica que la observaras en la pantalla de la terminal. pero como siempre podemos utilizar una tubería para redireccionar la salida a un archivo y evitar que se despliegue todo en pantalla:

exec 2>> /home/miarchivito.out
set -x