fer_fiat

¡Usuarios de Taringa! este es mi primer post! El motivo del mismo es brindarles información acerca de las inmobiliarias de la Ciudad de Buenos Aires. El ámbito inmobiliario está bastante regulado ya que obviamente no estamos hablando de un producto que compramos en cualquier lado, si no el inmueble que mayormente es el bien más importante y fundamental de una persona. Las inmobiliarias destinadas al marketing de venta del inmueble designado, tienen que cumplir ciertas reglamentaciones de un colegio llamado C.U.C.I.C.B.A (Colegio Único de Corredores Inmobiliarios de la Ciudad de Buenos Aires). Lo principal que impone este colegio es una matriculación en el mismo lo cual corrobora que la inmobiliaria es legal, las mismas tienen que pegar un sticker al frente de su local o si son oficinas, debe estar encuadrado y colgado. EL sticker es el siguiente. Y tiene que tener en una línea el nombre del matriculado, y en la otra línea el número de matricula. Con esto se intenta detectar a las inmobiliarias ilícitas. También pueden entrar a este link, que es otra opción ya que no sería extraño que se falsifique el sticker. Este es el padrón de matriculados del C.U.C.I.C.B.A, en el campo ingresan el nombre, razón social o número de matricula y luego apareceran los datos (N° de matricula, razón social o nombre, persona matriculada, teléfono donde se lo ubica o de su inombiliaria, dirección y estado). Link: http://www.cucicba.com.ar/padron.asp Otro método es ir directamente a la sección de infractores, es una base de datos similar a la anterior. Link: http://www.cucicba.com.ar/infractores.asp ¡Gracias por leer mi post! Comenten si la información les sirvió o piensan que les servirá ¡¡Saludos!!

Un Poco Sobre Inmobiliarias ¿Que tal Taringueros? El motivo del post es brindarles información acerca de las inmobiliarias de Buenos Aires. El ámbito inmobiliario está bastante regulado ya que obviamente no estamos hablando de un producto que compramos en cualquier lado, si no el inmueble que mayormente es el bien más importante y fundamental de una persona. Las inmobiliarias destinadas al marketing de venta del inmueble designado, tienen que cumplir ciertas reglamentaciones de un colegio llamado C.U.C.I.C.B.A (Colegio Único de Corredores Inmobiliarios de la Ciudad de Buenos Aires) si bien funciona principalmente para la Ciudad de Buenos Aires, también hay miembros en Provincia. Lo principal que impone este colegio es una matriculación en el mismo lo cual corrobora que la inmobiliaria es legal, y también unas reglas a seguir respecto a las comisiones y actos jurídicos. Las mismas tienen que pegar un sticker al frente de su local o si son oficinas, debe estar encuadrado y colgado. El sticker es el siguiente. Y tiene que tener en una línea el nombre del matriculado, y en la otra línea el número de matricula. Con esto se intenta detectar a las inmobiliarias ilícitas. También pueden entrar a este link, que es otra opción ya que no sería extraño que se falsifique el sticker. Este es el padrón de matriculados del C.U.C.I.C.B.A, en el campo ingresan el nombre, razón social o número de matricula y luego apareceran los datos (N° de matricula, razón social o nombre, persona matriculada, teléfono donde se lo ubica o de su inombiliaria, dirección y estado). Link: http://www.cucicba.com.ar/padron.asp Otro método es ir directamente a la sección de infractores, es una base de datos similar a la anterior. Link: http://www.cucicba.com.ar/infractores.asp Alquileres: Antes que nada: La locadora es quien alquila en inmueble, la locataria el inquilino. Si alguno alquila seguramente le deben haber pedido una garantía para respaldar el pago del contrato. La garantía promueve tranquilidad al propietario de que uno cumpla con el pago (para daños físicos en el inmueble está el mes de depósito), de lo contrario, se inician acciones legales contra el garante. Mucha gente lo que hace es comprar garantías por lo consiguiente pueden alquilar alegando que ese garante existe y responde por uno, pero si llega a haber un inconveniente durante la locación, se van a ver mucho más perjudicados que si tuviesen una garantía legal o real. Algunas inmobiliarias y particulares piden los informes de dominio pertinentes y ahi figura si la garantía es comprada o no y también el estado de la misma: si el inmueble está embargado o si está afectado de alguna otra forma. Por lo general las inmobiliarias administran lo que alquilaron, como consejo, solamente paguen y hagan algún que otro comentario, los problemas con el departamento es mucho mejor y más rápido de solucionarlos directamente con el propietario. Un caso no muy visto es que una persona X puede ser el locador de un inmueble y firmar el contrato, lo que se tiene que ocupar esa perona es que el dinero llegue realmente al propietario. No se metan en esto, no es muy aconsejable... Comisiones: Con respecto a las comisiones, la mayoría tienen parametros diferentes al estipulado. Lo normal para un alquiler es 1 mes y medio como honorarios inmobiliarios para viviendas (por lo general se cobran 2 meses) y el 5% del total de contrato para locales y a parte de lo antes mencionado, un dinero extra ($ 300.- aprox.) para los informes de dominio, cuando se hacen renovaciones, e cobra 1 mes. Lo normal para una compra es el 4% del valor del inmueble o contraoferta para el comprador y el 2% para el vendedor, sin embargo, la inmobiliaria puede cobrarle del 1% al 100%, si cobra el 90% y el propietario acepta, es legal ¿Qué loco no? Por otra parte, de la escritura se encarga el escribano, suele cobrar el 3% del total de la venta. Casos típicos de inmobiliarias ilegales: A parte de llevar mal una operación, lo más común es tomar más de una reserva, quedarse con el mejor postor y quedarse con las otras reservas con argumento falaces. Extra: Venta directa y simultanea: La venta directa: como bien su nombre lo dice, es reservar, firmar boleto, firmar escritura y ocupar. (Puede no firmarse boleto y saltar direcatmente a la escritura traslativa de dominio). La venta simultanea: se deja una reserva ad referéndum de la busqueda de otro inmueble para el vendedor, se establece un plazo de días para que el vendedor busque otro inmueble de su conformidad, luego pasa a ser como una venta directa. A la firma del boleto de compra-venta se paga el 30% del total del valor o contraoferta. Bueno espero que les haya servido de algo o por lo menos les sirva en un futuro. Fuente: Yo, soy inmobilario, si tienen alguna pregunta consulten!

Gifs y esas boludeces de la web Buenas gente de T!, acá les dejo unos gifs e imágenes, tarda en cargar, mientras carga, intenten hacer el numero 6 con la mano derecha y girar en sentido horario la pierna derecha. Gifs Imágenes Demotivationals Espero que les guste! : Tumblr y Taringa!

Logueo sin password por SSH Hola Taringueros Linuxeros! Aca les dejo un tuto para loguerse por ssh a una terminal remota por SSH, sin password en unos pocos pasos. Es algo copado para los que utilizan mucho este servicio ya que ahorra tiempo y evita pifiadas de clave. En este caso host@local va a ser la terminal de donde vamos a efectuar el logueo y host@remoto es la terminal a donde nos queremos loguar. 0. Antes que nada, si no tienen el ssh arriba en la terminal remota, procedemos a instalarlo en forma local, los comandos a continuacion son sin sudo, o sea logueados como root, si no tienen el logueo como root habilitado usen sudo antes de cada comando: Distros fork de Debian: apt-get install ssh Distros fork de Red Hat: yum install openssh-server openssh-client Distros fork de Arch: pacman -Sy openssh Distros fork de Slackware: installpkg openssh-4.2p1-i486-1.tgz Distros fork de Gentoo: emerge -av net-misc/openssh Aclaraciones: Para usuarios de Arch levantan el daemon invocando: # rc.d start sshd Y para que se levante al inicio despues de una rebooteada editan el archivo /etc/rc.conf añadiendo "sshd" a la siguiente fila DAEMONS=(syslog-ng network netfs dbus gdm sshd crond) Para usuarios de Gentoo levantan el daemon invocando: # /etc/init.d/sshd start Y para que se levante al inicio despues de una rebooteada: # rc-update add sshd default De todos modos si ven que el servicio no esta arriba, invocando cualquiera de estos 2 comandos en cualquier distro, deberían startear: # service sshd start # /etc/init.d/sshd start Tambien vamos a necesitar saber la IP del host remoto, por ende tipeamos: # ifconfig Este comando imprime los datos de cada interfaz de red (eth0, wlan0, ppp0) 1. Desde la maquina de donde nos queremos loguear al host remoto, tipeamos sin necesidad de estar como root o invocando a sudo: # ssh-keygen -t rsa Rsa es el tipo de encryptación, pueden usar dsa si desean. Rsa loguea mas rápido pero es más seguro, dsa es a la inversa. Lo anterior les va a producir algo como esto: Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): ----> presionamos Enter Enter same passphrase again: ---> Idem Your identification has been saved in /root/.ssh/id_rsa. ---> yo estaba logueado como root, aca les puede aparecer su usuario Your public key has been saved in /root/.ssh/id_rsa.pub. ---> Idem. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx host@local The key's randomart image is: +--[ RSA 2048]----+ | | | . | | . . | | . + . o| | . S O o .o| | + + o .oo| | .. . . .o| | .o . o+| | .. . oE| +-----------------+ La key fingerprint es una combinación de números y letras 2. Ahora efectuamos los siguientes comandos. En donde dice "host" va el nombre del usuario "remoto" va la IP del host al que nos queremos loguear, por ejemplo [email protected]: host@local: ssh host@remoto mkdir -p .ssh host@remoto password: (aca tipean la password del host remoto) host@local: cat .ssh/id_rsa.pub | ssh host@remoto 'cat >> .ssh/authorized_keys' host@remoto password: 3. Con esto bastaría, prueben ahora loguearse. Algo más que se puede hacer para que sea todavía más practico es editar los alias de la bash (bash es el tipo de shell, al igual que sh o dash). El archivo se ubica en /home/user/.bashrc para los que esten con user común o /root/.bashrc para los que esten como root. La línea de texto va a ser añadida al final del archivo. Mi editor de preferencia es nano y yo voy a poner que me quiero loguear a proliant. Los alias son comandos que pueden ser creados por uno mismo, tambien pueden crearse algo con su gestor de paquetes de la misma manera nano /home/user/.bashrc alias proliant='ssh host@remoto' Cerramos el archivo y en la terminal efectuamos el siguiente comando para que tenga efecto la mod (en la mayoria de los casos es bash la shell predeterminada: /bin/bash 4. Probamos lo anterior introduciendo el comando que craeamos bajo alias: # proliant Y eso es todo, con esto conseguimos una forma más cómoda para loguearse por ssh. Un dato que por ahi le sirva a alguno: cuando busquen tutos de como hacer las cosas, si aparece el signo "$" antes del comando significa que está siendo ejecutado como user, si aparece "#" es que está siendo ejecutado como root. Y los "#" que aparecen antes de una línea de texto en un archivo significa que están comentadas, por ende no tienen efecto a menos que la proceda un "!", esto se suele usar en los scripts y se denomina shabang, con eso se indica en que shell se va a efectuar, ej: #!/bin/bash". ACLARACION: esto NO DEJA SIN PASSWORD al logueo por SSH, solamente la máquina que tenga la key fingerprint que está alojada en el host remoto en .ssh/authorized_keys. De otra manera NO puede loguearse ninguna otra persona sin tipear la password. Saludos!

Backup Server En este howto vamos a levantar un servidor de backup sin costo de software alguno, efectivo y seguro. Antes que nada: Si bien los sistemas GNU/Linux son muy confiables a la hora de servers o desktops, la falla siempre puede ocurrir, sea por usuario, por software o por hardware. En el caso de los servers, este método lo utilizo en los servers que administro y me dió muy buen resultado por eso lo comparto. En este post no explico como incluirlo en un Tape, solamente en HD comunes. Cuando se ejecuta un comando está presente el "#" es que está siendo ejecutado como root, y si aparece "$" es que está siendo ejecutado como usuario común, esta aclaración va para los ubunteros, fedoreros, manjareros y todos los "eros" que no user root. Para los users de slacky y gentoo algunos pasos no los especifico, uds. ya saben que hacer. Los users de OpenSUSE usen zypper o YasT, es a su elección. Los users de FreeBSD tienen que cambiar 4 cosas en la configuración que se van a dar cuenta. El método utilizado es RSNAPHOT (RSYNC) + SSH + CRON SSH: (Secure SHell, por sus inicales) lo deben conocer, es el protocolo de consola remota utilizado en los sistemas Unix y Unix like, es el logueo a una terminal remota en donde el input y la información se pasa de manera encryptada, tiene muchas cualidades entre las cuales está el SCP (Secure Copy Protocol) el cual sirve para transferir archivos de manera encryptada de una terminal a otra. RSYNC: (Remote Synchronization, por sus iniciales) En algún que otro post lo habrán sentido nombrar, este protocolo sincroniza los archivos de una terminal a otra, de ahí sale el nombre, si se fijan por ejemplo en la página de los kernel de GNU/Linux (http://www.kernel.org) hay una opción que es mediante RSYNC. CRON: esta es una vieja función de los sistemas Unix y Unix like, lo que hace es ejecutar comandos a un tiempo determinado, hay programas que cargan su configuración en CRON como Debian cuando hay actualizaciones que hace que se ejecute el comando "apt-get update" cuando iniciamos sesión. Nosotros vamos a ejecutar el comando que describo más adelante. RSNAPSHOT: (Remote SNAPSHOT, por sus iniciales) para los que curten un poco de inglés ya saben lo que significa y para los que no significa "Fotografía remota". Es un frontend para RSYNC, simplifica la tarea de juntar RSYNC, CRON y SSH mediante un archivo de configuración alojado en /etc. Arrancamos: ¿Qué distro elijo? Bueno esto es a elección... Yo como dije en mi anterior post utilizo Debian, el problema es que si quieren armar un RAID por hardware manejado por ejemplo por Nvidia hay que editar unas líneas del kernel ya que es software privativo, entonces les va a convenir Ubuntu Server ya que posee los drivers (nvidia_cajiage) cargados en el kernel y se los va a reconocer, en distros basadas en el sombrero rojo (Red Hat) como Fedora, también se los reconoce. Libre elección muchachos/as, en el mundo de GNU/Linux se prioriza la libertad del usuario.... ¿Y por dónde empiezo? La idea es que los datos a backupear estén separados de / (o sea del root),en otra partición, por el simple hecho de que si alguno se manda alguna macana con el sistema, los datos continúen intactos. Como la mayoría de los bootstrap de ahora vienen con la opción de poner /home como partición separada y punto de montaje, vamos a utilizarla. Algunas distros vienen con la opción de encryptar la partición lo cual me parece genial y utilizo, para este punto voy a explicarlo al final del post porque es medio complicado cuando hay un reboot y el server no está a mano... Si están creando un sistema virgo: Separen /boot como partición y asignelnle algo entre 150mb a 500 mb. Al / (root) denle 15gb. Al swap denle el doble de su memoria RAM. Y finalmente a /home denle el resto del espacio del disco. NO CREEN USUARIO! Dejen solo a root. En distros suderas dejen todo como está, se modifica más adelante. Si están con un sistema manoseado y quieren destinar /home para backup (MIGREN LOS ARCHIVOS QUE TENGAN). Hagan a /home una partición e incluyanla en el FSTAB (/etc/fstab) (está más abajo subrayado). El FSTAB es el archivo de configuración donde están específicados los puntos de montaje. (root, home, swap, quotas, etc.) Si tienen un disco al pedo: Incluyanlo en el FSTAB para que se monte durante el proceso de inicio un sistema ya armado, de la siguiente manera: Fijense en su BIOS si les figura el otro disco. En el sistema, su HD inicial siempre les va a aparecer como /dev/sda + el número de partición... El tema es que el HD entero se representa como /dev/sda solo Entonces /dev/sdb va a aparecer como su HD secundario, si están con tecnología vieja y no les aparece hay que jumpearlo, googleenlo que es una bolduez. En la shell ejecuten como root el comando "cfsidk /dev/sdb". En sistemas que usan sudo, tipeen "sudo cfdisk /dev/sdb". Van a ver una interfaz en la consola: Ignoren lo que dice en la imagen, es para dar una idea... Entonces van a borrar la partición existente con los tags que le pone cfdisk, en este caso es "Delete" y si no tienen nada el tag es "New". El tipo de partición (Type) es "Linux" que corresponde al número 83. Cuando terminen de crear la partición en el disco, tirando el comando "fdsik -l" les va a aparecer como "/dev/sdb1". Ahora hay que formatearlo introduciendo el siguiente comando: $ mkfs.ext4 /dev/sdb1 La terminal les va a poner un par de cosas como "Journal recovery" que simplificando viene a ser como el punto de recuperación de los EXT4. Usen el tipo de sistema de archivos que se les cante, puse EXT4 porque hoy en día es lo que más se utiliza, sin embargo XFS está comprobado que para backups muy grandes es el que mejor rinde. Ahora vamos a hacer que se monte (esto les sirve a los que crean una partición desde un sistema manoseado) Editen como root con su editor de texto preferido como "nano" el archivo "/etc/fstab" Su disco primario donde está /boot, / y el swap va a figurar como /dev/sda + el nro. de partición. Como dije antes el nuevo disco va a ser /dev/sdb1. # nano /etc/fstab Les va a aparecer una pantalla que está separada por supuestas columnas (digo supuestas porque no se entienden bien ya que quedan corridas). Agreguen el final la siguiente línea: /dev/sdb1 /home ext4 uid=1000,rw errors=remount 2 Les explico: /dev/sdb1: es lo que se va a montar. /home: es el punto de montaje ext4: es el tipo de sistema de archivos uid=1000 sería el UID del user que va a tener permisos sobre este disco ,rw: son lo permisos que se le asignan al usuario, en este caso es RW que signifa Read-Write (Lectura y escritura). errors=remount: esto hace que se remonte en caso de falla (dump como dice el manual) 2: Esto es utilizado por el fsck, cada tanto el sistema checkea los discos en caso de errores (como fue en algun momento oscuro el chkdsk para Windows), el nro 1 es para el root, el nro 2 es para nuestra partición, el orden hace que root se checkee primero y luego lo que creamos. Una vez creado el sistema con todo updateado vamos a setear la red: Configuren su red con IP fija que acá va a ser por ejemplo 192.168.0.78. La puerta de enlace 192.168.0.234, los DNS 8.8.8.8 y la interface "eth0". En RED HAT no viene nano como editor por default, usen vim o instalenlo con "yum install nano". DEBIAN: # nano /etc/network/interfaces auto eth0 iface eth0 inet static address 192.168.0.78 netmask 255.255.255.0 gateway 192.168.0.234 network 192.168.0.0 broadcast 192.168.0.255 dns-nameservers 8.8.8.8 # service networking restart RED HAT: # ifconfig (para copiar su mac "HWaddr" # nano /etc/sysconfig/network NETWORKING=yes HOSTNAME=backup GATEWAY=192.168.0.234 # nano /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static DHCPCLASS= HWADDR= "acá va su mac" IPADDR=192.168.0.78 NETMASK=255.255.255.0 ONBOOT=yes #nano /etc/resolv.conf nameserver 8.8.8.8 # service networking restart ARCH: Creen el archivo de configuración para systemd: #nano /etc/conf.d/network@eth0 address=192.168.0.78 netmask=24 broadcast=192.168.0.255 gateway=192.168.0.234 Ahora creen el archivo para que systemd lo cargue: #nano /etc/systemd/system/[email protected] Description=Network connectivity (%i) Wants=network.target Before=network.target BindsTo=sys-subsystem-net-devices-%i.device After=sys-subsystem-net-devices-%i.device Type=oneshot RemainAfterExit=yes EnvironmentFile=/etc/conf.d/network@%i ExecStart=/usr/bin/ip link set dev %i up ExecStart=/usr/bin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev %i ExecStart=/usr/bin/ip route add default via ${gateway} ExecStop=/usr/bin/ip addr flush dev %i ExecStop=/usr/bin/ip link set dev %i down WantedBy=multi-user.target Ejecuten los siguientes comandos para cargar su configuración: # systemctl enable [email protected] # systemctl start [email protected] Aseguremos un poco el servidor Usar root siempre es peligroso: entonces vamos a crear un usuario que pueda hacer sudo para los comandos rsnapshot y rsync, sin que se tipee la contraseña. El user se va a llamar "carrier" #useradd carrier (con esto agregan el usuario) #passwd carrier (typeen una password buena) Instalamos sudo: DEBIAN: # apt-get install sudo RED HAT: # yum install sudo ARCH: # pacman -S sudo Editamos el archivo de configuración de sudo: # visudo Y agregamos al final del archivo lo siguiente: carrier ALL=NOPASSWD:/usr/bin/rsync carrier ALL=NOPASSWD:/usr/bin/rsnapshot Con esto nos aseguramos que el usuario carrier ejecute sin contraseña los comandos rsync y rsnapshot como root, pero que no pueda ejecutar ningún otro comando ni poniendo la clave como root. Instalamos SSH y de paso RSNAPSHOT para más adelante: DEBIAN: # apt-get install rsnapshot ssh RED HAT: # yum install rsnaphot sshd ARCH: # pacman -S rsnapshot ssh Seguridad para SSH: Bien... Vamos a configurar unas cosas para que el sistema sea seguro ante algún ataque por ssh... 1. Si bien SSH es bastante seguro nunca nadie está exento, procederemos a aplicar algunas politicas de seguridad al servidor: a. Editen el archivo /etc/ssh/sshd_config: # /etc/ssh/sshd_config Busquen la línea que diga "Port 22", esto especifíca el puerto (que el default siempre es el 22). Cambienlo por otro número, quedandoles por ejemplo "Port 2345". Ahora cada vez que se logueen al servidor van a tener que especificar el puerto con el argumento -p. Por ejemplo: "ssh [email protected] -p2345" Ahora busquen la línea "PermitRootLogin", por default viene con la opción "yes" esto permite que se pueda loguear al servidor por ssh directamente como root, cambien la opción por "no" quedando "PermitRootLogin no". Instalamos "denyhosts" que bloquea las IPs que le erran a la contraseña según la cantidad de veces que especifiquemos: DEBIAN: # apt-get -y install denyhosts RED HAT: # yum -y install denyhosts ARCH: # pacman -S denyhosts Editamos la configuración: # nano /etc/denyhosts.conf Hay muchas cosas... pero nos vamos a centrar solo en algunas En nano apreten "Ctrl+W" que es para buscar en el archivo de texto, en vim es haciendo / y escribiendo lo que van a buscar Las líneas que nombro abajo si aparecen comentadas, descomentenlas. - La primer parte es donde denyhosts guarda los logs, descomenten según su distro. HOSTS_DENY = /etc/hosts.deny - En la línea "DENY_THRESHOLD_INVALID = " se especifica los intentos que pueden haber de logueo con una cuenta no existente en el sistema antes de que la IP sea bloqueada, dejenla por ejemplo así: DENY_THRESHOLD_INVALID = 3 Así pueden haber 3 intentos antes de que la IP sea bloqueada. - En la línea "DENY_THRESHOLD_VALID = " se especifica los intentos que pueden haber de logueo con una cuenta existente en el sistema antes de que la IP sea bloqueada, dejenla por ejemplo así: DENY_THRESHOLD_VALID = 4 Así pueden haber 5 intentos antes de que la IP sea bloqueada. - En la línea "DENY_THRESHOLD_ROOT = " se especifican los intentos que pueden haber de logueo con la cuenta root antes de que la IP sea bloqueada, como especificamos que no se permita el acceso por ssh con root, es obvio que es una IP maliciosa, así que este va a ser más estricto: DENY_THRESHOLD_ROOT = 1 Así puede haber un intento antes de que la IP sea bloqueada. - En la línea "DENY_THRESHOLD_RESTRICTED = " se especifican según los usuarios que figuren en "WORK_DIR/restricted-usernames", los intentos de logueo con esos usuarios específicos antes de que la IP sea bloqueada. En la lista carguen al usuario "carrier" que es con quien nos logueamos por ssh y denle una tolerancia de 2 por si le erran a la clave. DENY_THRESHOLD_RESTRICTED = 2 Así pueden haber 2 intentos antes de que la IP sea bloqueada, el directorio "WORK_DIR" se especifica en lo que viene ahora - En la línea "WORK_DIR = " pongan el directorio de trabajo de denyhosts, acá va a el archivo restricted users. Si no me equivoco viene por default "/var/lib/denyhosts", si no es ese, especifiquenlo: WORK_DIR = /var/lib/denyhosts O pongan el que quieran - En la línea "SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=" ponganle "YES", esto es para que en el log figuren logueos sospechosos, o sea de IPs poco comunes. SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=YES - En "HOSTNAME_LOOKUP=" ponganle "YES", esto es para que en el log aparezca el hostname de la IP si está disponible. HOSTNAME_LOOKUP=YES - En "LOCK_FILE" se especifica el archivo que hace que denyhost corra solo una vez, aparecen las recomendaciones según el tipo de distro, si no está hecho automáticamente, descomenten según corresponda. Por ejemplo: # Redhat/Fedora: LOCK_FILE = /var/lock/subsys/denyhosts # # Debian #LOCK_FILE = /var/run/denyhosts.pid # # Misc #LOCK_FILE = /tmp/denyhosts.lock Los servidores remotos Ok... Ahora vamos a suponer que tenemos 2 servidores, uno es un servidor de mail y el otro una base de datos, los hosts van a ser "mail o 192.168.0.23" y "database o 192.168.0.45" respectivamente. En cada servidor creense el usuario "carrier" siguiendo los mismos pasos que usaron para crearlo en el host local y también con la configuración de sudo sin la línea de rsnapshot. Como estamos comunicandonos por SSH, hay que efectuar un logueo sin password, esto es posible mediante llaves de autenticación. La terminal que no posea las llaves de autenticación va a tener que poner la contraseña. Generamos las llaves con el usuario CARRIER: $ ssh-keygen -t rsa RSA es un tipo de encriptación bastante seguro. Les va a promptear 3 cosas, apreten Enter en las 3. Creamos el archivo "config" en /root/.ssh # nano /root/.ssh/config Y escribimos lo siguiente: Host mail Port 22 Hostname 192.168.0.23 User carrier IdentityFile /home/carrier/.ssh/id_rsa Host database Port 22 Hostname 192.168.0.45 User carrier IdentityFile /home/carrier/.ssh/id_rsa Ahora para loguearnos a los servidores deseados: # ssh-copy-id -i /home/carrier/.ssh/id_rsa.pub carrier@mail # ssh-copy-id -i /home/carrier/.ssh/id_rsa.pub carrier@database Prueben logueandose por ssh de la siguiente manera: # ssh mail # ssh database Deberían poder loguearse sin prompteos de password y sin problemas... Una vez logueados van a crear el archivo "sudo_rsync.sh" en el directorio "/usr/local/bin" #nano /usr/local/bin/sudo_rsync.sh. Esto va a hacer que cuando se invoque rsync en los servidores remotos, haga sudo. Y van a añadir lo siguiente: #!/bin/bash /usr/bin/sudo /usr/bin/rsync "$@"; Vamos de vuelta al servidor de backup: Creen una carpeta en /home con el nombre que quieran, ese va a ser el directorio donde se van a alojar nuestros backups, yo le puse "storage". Dentro de la carpeta creen "mail" y "database". RSNAPSHOT crea un archivo de configuración en /etc que se llama "/etc/rsnaphot.conf". Procederemos a editarlo, en todos los casos respeten las "/" al final de los directorios. # nano /etc/rsnapshot.conf Busquen las líneas para que se les haga más fácil como en denyhosts. - En la línea "snapshot_root" va el destino de los backups, así que vamos a especificar la carpeta que creamos: snapshot_root /home/storage/ - La línea "#cmd_ssh /usr/bin/ssh" debe estar descomentada para usar SSH, descomentenla. - Si están usando LVM (Logical Volume Manager) que no lo expliqué pero quizas alguno lo hizo y le sirva, descomenten estas líneas : linux_lvm_cmd_lvcreate /sbin/lvcreate linux_lvm_cmd_lvremove /sbin/lvremove linux_lvm_cmd_mount /bin/mount linux_lvm_cmd_umount /bin/umount - Busquen la línea "retain" esto establece los INTERVALOS DE BACKUP: estas líneas especifican cuanto tiempo el backup va a ser retenido antes de que se pise uno a otro, los mismos están especificados de la siguiente manera: en horas (hourly), díariamente (daily), semanalmente (weekly) y mensual (monthly). Esto queda a criterio de cada uno, yo posteo de la manera que lo tengo configurado, sin backup por hora. Cada número correspone a la unidad que se le está asignando, por ejemplo: retain daily 7 retain weekly 4 retain monthly 6 Esto quiere decir que: Los backups de día se pisan cada 7 días. Los backups de semana se pisan cada 4 semanas. Los backups de mes se pisan cada 6 meses. - En la línea "logfile" se establece la escritura de los logs, los mismos comunmente van en la carpeta /var/log, por defecto viene "/var/log/rsnapshot.log". La línea aparece comentada, descomentenla y cambien el destino si lo desean. - La línea "rsync_short_args" carga los argumentos cortos, debe ser descomentada y agregarle como parámetros los argumentos -avz (archive, para que sea recursivo, verbose, para que sea más explicito lo que dice que está haciendo y z para que comprima) quedando así: rsync_short_args -avz - La línea "rsync_long_args" contiene a los argumentos largos, también debe ser descomentada y agregarle el parametro --rsync-path='sudo_rsync.sh' para que se ejecute como root cuando va a buscar los datos, quedano de la siguiente manera: rsync_long_args --rsync-path='sudo_rsync.sh' --delete --numeric-ids --relative --delete-excluded - La línea "ssh_args" carga parametros para el ssh, la vamos a descomentar y asegurarnos que el argumento sea "-p 22" Ahora vamos a cargar políticas de backup: - Busquen la línea "BACKUP POINTS" Acá aparecen ejemplo de scripts para backup... Dejenlos que les pueden servir si quieren guardar archivos locales a la partición de backup por si root se rompe, ya se van a dar cuenta como hacerlo . Supongamos que en el servidor "mail" hay un sistema postfix+dovecot+unix_user_backend y tenemos que backupear las bandejas de entrada en formato Maildir. Al utilizarse los usuarios del sistema, todo lo que corresponda a mails va a estar situado en la carpeta de /home de cada usuario. Entonces vamos a backupear todo /home. El host "database" no es por casualidad, rsnapshot puede hacer que se ejecute un dump de una base de datos y traerlo, lo explico más abajo así no se mezcla. Añadimos un script para que quede fachero e indique la hora a la cual se está realizando en el log . La sintáxis entre "backup", el host o el comando y la carpeta de destino o el "unused" está separada por TAB, no por espacios. ### MAIL ### backup_script /bin/date "+ Iniciando el backup de la carpeta HOME del servidor MAIL y la db de DATABASE siendo las %c" unused1 Vamos a probar que funcione... # rsnapshot daily Si funciona bien, va a imprimir en la terminal todo lo que está haciendo y obviamente no debería haber ninguna línea que empiece con "error:", cuando terminen vayan a ver los logs y busquen si hay algo raro: # nano /var/log/rsnapshot.log Entren a la carpeta /home/storage/mail y verifiquen si tienen lo mismo que en el servidor. Si es así ya la parte de mail la tienen liquidada, ahora vamos a ver que onda con database: Como dije antes el host "database" no es casualidad y si queremos hacer un respaldo de una base de datos remota lo podemos hacer de la siguiente manera, acá lo explico con MySQL, la sintáxis para MariaDB es practicamente la misma... Entren al servidor database y logueense a MySQL: # mysql -u root -p Esta va a ser la única vez que usemos al usuario root de MySQL ya que se puede destinar un usuario (yo lo llamé "dumper" que solo tenga los privilegios necesarios para realizar un DUMP de una base evitando la tipica "GRANT ALL PRIVILEGES" que le da todos los permisos a un usuario sobre la misma. La base se llama "taringa", la clave de dumper es "linux" y el dump se llama dumptaringa.sql mysql> CREATE USER 'dumper'@'localhost' IDENTIFIED BY 'linux'; mysql> GRANT SHOW VIEW,LOCK TABLES,SELECT ON taringa.* TO 'dumper'@'localhost' IDENTIFIED BY 'linux'; mysql> exit Para probar si el el dump se realiza correctamente ejecutamos: $ mysqldump -udumper -p taringa > /home/carrier/dumptaringa.sql Esto les va a generar el dump de la base en /home/carrier Con esos comandos ya pueden hacer un resguardo de la base sin usar root, ahora volvamos al servidor de backup y en "/etc/rsnapshot.conf" abajo de la configuración de "MAIL" añadimos lo siguiente: ### DATABASE ### backup_script /usr/bin/ssh carrier@database "mysqldump -udumper -p'linux' taringa > /home/carrier/dumptaringa.sql unused2 backup carrier@database:/home/carrier/dumptaringa.sql database/ Faltaría tirarlo en cron, para eso vamos a hacer lo siguiente: Si RSNAPSHOT no lo cargó en "/etc/cron.d" vamos a cargarselo: # nano /etc/cron.d Y agreguen: 05 3 * * * root /usr/bin/rsnapshot daily 0 3 * * 1 root /usr/bin/rsnapshot weekly 30 2 1 * * root /usr/bin/rsnapshot monthly Esto matchea la configuración de RSNAPSHOT, todos los días a las 3:05am. va a ejecutarse "rsnaphot daily, los otros corresponden a una vez por semana y una vez por mes. Hasta acá ya tenemos los logueos automatizados, las políticas de backup y lo que queremos backupear. ¿Qué pasa si encryptaste la partición? Sinceramente es un pita (pain in the ass) , al rebootear si el servidor no está a mano para poner la clave, el sistema no continúa booteando y se clava en initramfs. Peeeeero para eso existe DROPBEAR que genera un daemon de ssh en el initramfs y busybox que es una shell mínima con comandos limitados pero útiles. Vamos a instalarlos: DEBIAN: # apt-get -y install dropbear busybox RED HAT: # yum -y install dropbear busybox ARCH: # pacman -S dropbear busybox -Ahora hacemos que arranque (si dropbear no lo hizo, carguenlo en el initramfs de la siguiente manera) # cat >> /etc/initramfs-tools/initramfs.conf DROPBEAR=y BUSYBOX=y Cierran CAT con "Ctrl-D" -Ahora tiene que cargarse la configuración de red al booteo del initramfs, también se puede hacer editando una línea del kernel, no es jodido pero yo uso esta opción. # cat >> /etc/initramfs-tools/conf.d/network-config export IP=192.168.0.78::192.168.0.234:255.255.255.0:backup:eth0:off:8.8.8.8 Con eso ya queda cargada la red en initramfs. -Cuando rebooteen, entren por ssh al servidor, usando el puerto 22 y el usuario root. Les va a tirar a una shell que se llama ash, una sh mínima. # busybox ps -le Les va a tirar la lista de procesos, busquen el que empieze con "cryptroot" y termina con "key-file=-". Copienlo y peguenlo en su bash, denle enter y les va a promptear la clave para desbloquear la partición, se van a quedar afuera del ssh, loguense de nuevo con la configuración normal. Es una solución rústica pero universal ya que para Ubuntu como utiliza Plymouth se complica para hacerlo mediante scripts. Con esto tienen un servidor de backup incremental, que les genera una "fotografía" exacta del día anterior, alteren la configuración a sus necesidades y si tienen algún problema escribanlo en los comentarios a ver como puedo darle una mano. Digo en los comentarios porque capaz a otro también le sirva. Saludos!

Hola Taringueros! Como a varios les habrá pasado (o les pasará) después de upgradear, el driver Broadcom 802.11 tira error y no hay forma mediante interface de poder solucionarlo. Googleando encontré varias maneras de solucionar el problema pero ninguna me dió resultado excepto la siguiente: Abren terminal (Ctrl + Alt + T) Instalan los paquetes module-assistant y wireless-tools: # aptitude update (o install si no lo tienen) # aptitude install module-assistant wireless-tools Arman e instalan un paquete broadcom-sta-modules-* usando Module-Assistant: # m-a a-i broadcom-sta Blacklistean el módulo brcm80211, para que no joda con el soporte de los dispositivos BCM4313, BCM43224 y BCM43225: # echo blacklist brcm80211 >> /etc/modprobe.d/broadcom-sta-common.conf Rearman su ramdisk inicial, para los módulos de la blacklist de /etc/modprobe.d/broadcom-sta-common.conf con initramfs: update-initramfs -u -k Descargan los conflictivos: # modprobe -r b44 b43 b43legacy ssb brcm80211 Cargan el wl module: # modprobe wl (Acá debería tomar la wireless) Fijense que la interfase esté bien: # iwconfig Si se va a implementar el modelo, recomiendo utilizar primero el Synaptic. Tipear broadcom e instalar el source del kernel y b43-fwcutter. Por lo que leí este modelo de Dell resultó bastante conflictivo en este aspecto. La solución la encontré acá: http://wiki.debian.org/wl#Installation Por favor comenten si les funcionó o no. Gracias por leer el post!

Compilación de alpedismo Buenas gente de T!, acá les dejo unos gifs e imagenes, tarda en cargar, mientras carga, piensen que material van a ver en P!, en un rato... Gifs Imágenes Demotivationals Espero que les guste! : Tumblr, T! y mi tiempo al pedo de casi un año.

Básicamente cambió todo el paradigma porque anuló la típica justificación dev: "that's weird, it works on my machine!", que sería "que raro, en mi máquina funciona!". ¿Qué hizo Docker? Docker supo abstraer, de forma moderna y efectiva, una teconología popularmente desconocida llamada LXC (LinuX Containers), asimismo integrar aderezos tales como una capa de FS reutilizable, una API REST (via HTTP/S), limitación de recursos (cgropus, cosa de google), facilidades sobre la exposición de servicios bindeados en puertos (managea IPtables), la posibilidad de forwardear logs a stacks dedicados (gelf -> ELK) y otras bondades más. ¿Los contenedores son VMs? No, no lo son. Una VM bootea un kernel, el container no lo hace, utiliza el kernel del host. Esto significa que el overhead de la máquina virtual queda erradicado, por otro lado si lo que ejecuta ese container genera un kernel panic, se va todo al pasto; cosa que hoy en día con la estabilidad proporcionada por el kernel Linux hace prácticamente algo impensado. El problema con LXC pelado fue que las librerías que tenían que utilizar estos container si o si tenían que estar instaladas en el host. Por eso Docker implementó una manera de (re)utilizar capas de FS que contienen binarios y librerías necesarios para cada necesidad. Por ejemplo si en Fedora se corre 'docker run -it ubuntu:14:04' tenemos un container que "corre" Ubuntu y allí mismo se puede tirar "apt-get update", sin dejar de ser la distro Fedora. Recuerden: Linux es un kernel, no un sistema operativo. El concepto de container es poder abstraer uno o más procesos (lo ideal es uno) en un namespace distinto al de ejecución común. Esto es clave porque puede hacer entender de que un contenedor (container) no es una máquina virtual, si no un proceso ejecutado sobre el kernel pero en un namespace diferente Quizás esto tenga sentido para los ops que les interesa el rendimiento, aunque es cuestionable en throughtput de red a comparación de una VM en KVM ¡Pero es tranquilo que es hablando de la implementación básica! Ejemplo práctico $ cat "<h1>Ejemplo Taringa</h1>" > index.html && docker run -it -p 80:80 -v $PWD/index.html:/usr/share/apache2/htdocs/index.html httpd Agregar :z despues del html si son users de distros con SELinux ¿Cómo me simplifico la vida siendo dev? 1. Instalá docker (está en los repo oficiales de cualquier distro, y también te proveen uno para versiones nuevas, igual para Win y macOSX) 2. Entendé lo que hace una Dockerfile 3. Generá tu imagen 4. Profit ¿Cómo me simplifico la vida siendo op? 1. Instalá docker 2. Creá un repositorio de imágenes 3. Enforceá que los devs deployeen su aplicación en containers 4. Asegurate que los recursos que accede la aplicación no comprometen la seguridad 5. Proporcioná un medio común para los logs 6. ¡Tomá métricas y monitoreá! ¿Por qué esto es una especie de imposición? Por las necesidades del mercado... Hoy en día todo apunta a microservicios donde ese choclo de código aborreciente de milllones de líneas se dividió en partes, ej: autenticación, consulta de datos, persistencia en base de datos; todo conectado vía http, en una red donde esos servicios "se hablan". Esto también es bueno para los devs, porque se fraccionan las funcionalidades y pueden distribuir el trabajo de programar. ¿Ves como todo cobra sentido? Y más que nada porque el mercado neesita software de cálidad en poco tiempo y seguro. La posta la tenés acá: Versionado y repositorio Las imágenes de docker manejan un sistema de tags parecido al de git, de hecho una práctica común es tagear la imagen con el id del commit, por ejemplo taringa:e4437a74. A su vez las imagenes pueden ser alojadas en un repositorio privado o público con el que se interactua vía comandos similares a git: docker pull, docker push, docker tag y docker commit. El repo público de docker contiene imágenes oficiales de empresas o fundaciones que se involucraron, como por ejemplo Apache httpd, Neo4J, las distro más comunes, entre otras que también son de usuarios que se coparon y subieron una implementación propia de algo. Persistencia de datos y backup La idea de esto es que se corran aplicaciones stateless. Si es necesario se puede bindear un dir del sistema operativo base o utilizar un "driver" para volúmenes. Por default los volúmenes de los contenedores usan loop (/dev/loop), cosa que no es muy ajonsecable para prod, existen otros como overlayfs, ZFS, NFS (convoy), S3 (para Amazon) y LVM. Respecto al backup lo de los volumenes resuelve prácticamente todo. ¿Cómo tienen red y como se exponen los puertos? Cuando instales docker se autocreará un bridge llamado docker0 con la IP 172.17.0.1 generalmente. Todos los containers van a tener una IP en esa red. Existen "drivers" para red que hacen que los containers se vean entre hosts, cosa muy común en un cluster, ejemplo VXLAN con flannel o IPSEC con rancher. Se pueden crear y manipular redes on demand con docker network, incluso que el contenedor no corra con el bridge docker0 si no en la misma red que el host. El bindeo de puertos lo hace iptables. Security y limitación de recursos El uso de CPU puede ser limitado (cgroups) al igual que la memoria. Las capacidades de acceso al host pueden ser tuneadas finamente, esto con SELinux (por más que muchos lo odien) garantiza un nivel de seguridad máas que consistente. Eso si... si por alguna casualidad X container genera un kernel panic les va a planchar el host, recuerden que los containers no son VMs con kernel propio si no procesos en un namespace distinto sobre el mismo kernel. Si no me equivoco hace relativamente poco se mergeo una rama de código que incluye la posibilidad de que las fork bombs no rompan el host cuando se corren en un container. ¿Donde está la API? La encontrás en /var/run/docker.sock, si se configura puede ser bindeada a un puerto (generalmente el 2375 para http y 2376 para https). Clustering Por defecto docker implementa su modelo de cluster llamado swarm, hay otros proyectos geniales que imponen su propio modelo de cluster e incluso extienden las capacidades de docker, por ej: - Kubernetes de Google - Mesos de Apache - Cattle de Rancher Necesito una UI https://github.com/portainer/portainer , es excelente proyecto, acá la demo: Toda la info de X container la obtenes con docker info nombredelcontainer desde la terminal Quiero instalar docker en mi distro o buscala en tus repo, se que en Debian el paquete está como docker.io porque hay un dock que se llama igual. Windows Windows Server 2016 implementa docker y la pelotudez de "Windows Containers" que es casi lo mismo... También se puede bajar docker. Win10 tiene soporte para docker, antiguamente usaba VirtualBox, ahora HyperV y funciona bien.