Domotica y Software libre

OpenVPN Para mas informacion, ver  https://community.openvpn.net/ . Security note The configuration snippets here will produce a working server and client config. But take certain precautions if you want to use this approach in a production environment. Important things to avoid are: Do not store the easy-rsa CA files on the OpenVPN server. The server only needs ca.crt, server.crt, server.key and dh*.pem files The client only needs ca.crt, client.crt and client.key Avoid creating the encryption keys in a virtualized environment, as the random entropy may not be random enough to guarantee safe keys. Working with systemd With the transition to  systemd , OpenVPN no longer has a single monolithic init script, where every connection with a configuration file in  /etc/openvpn/  is started automatically. Instead, individual connections can be started and stopped with  systemctl . For example, to start a connection, run  systemctl start openvpn@ foo .service , where the co

Hace unos meses ya, hice el cambio de Debian (rama "testing") a Arch Linux. Uno de las distintas cosas a las que tuve que adaptarme en esa migración fue pasar de un sistema que  por ese entonces aún utilizaba SysVinit como gestor de servicios a uno que utiliza SystemD.  Para mí este era un punto importante, debido a las conocidas quejas que ha habido (y sigue habiendo) sobre SystemD. Hoy he querido compartir con vosotros mis impresiones sobre este sistema. La experiencia de usuario de un gestor de servicios no es algo que se constate de la misma forma que, por ejemplo, la de un entorno de escritorio o una aplicación en concreto.  El gestor de servicios es un elemento que, bajo funcionamiento normal, no se interpone en el funcionamiento del sistema: una vez que el sistema arranca el núcleo y este le pasa el relevo al proceso  init , si no hay problemas (y no debería haberlos si todo está configurado como debe), se iniciará la entrada de usuario (ya sea login en una c

En Java, hay varios parámetros para controlar el  tamaño inicial  y el  tamaño máximo  que puede tomar la máquina virtual. Además, hay que tener en cuenta el tipo de memoria sobre el que se quiere actuar:  heap ,  non-heap  ( PermGen ). Los valores por defecto que se dan corresponden a máquina virtuales de Sun, y son orientativos, porque pueden cambiar entre versiones de la máquina virtual. Los parámetros son los siguientes, fijándose a 128Mb. -Xms128m :  Tamaño de inicio  de la máquina virtual de Java a 128Mb. El valor por defecto son 64Mb. Si se aumenta este valor, se elimina el tiempo que se tardaría en aumentar el tamaño en memoria de la máquina virtual si se llegara el caso de que se necesitara más memoria, por lo que aumentaría el rendimiento en los casos que la aplicación haga uso intensivo de la memoria. -Xmx128m :  Tamaño máximo  de la máquina virtual de Java a 128Mb.  El valor por defecto son 128Mb. Si la aplicación supera el tamaño máximo de memoria que marca este pará

Kill: matar un proceso usando su PID La forma más complicada pero al mismo tiempo más precisa de matar un proceso es a través de su PID (siglas en inglés de “Identificador de Proceso”). Cualquiera de estas 3 variantes puede servir: kill -TERM pid kill -SIGTERM pid kill -15 pid Se puede usar el nombre de la señal (TERM o SIGTERM) que se desea mandar al proceso o su número de identificación (15). Para ver un listado completo de las posibles señales, sugiero verificar el manual de kill. Para ello, ejecutá: man kill Veamos un ejemplo de cómo matar Firefox: Primero, hay que averiguar el PID del programa: ps -ef | grep firefox Ese comando devolverá algo parecido a esto: 1986 ?        Sl     7:22 /usr/lib/firefox-3.5.3/firefox Usamos el PID devuelto por el comando anterior para aniquilar el proceso: kill -9 1986 killall: matar un proceso usando su nombre Este comando es bien fácil killall nombre_proceso Un dato a tener en cuenta al usar este método es que en caso de q

  En ocasiones nos podremos encontrar con la necesidad de monitorizar con Nagios un proceso (entendido como aplicación en ejecución) que se encuentra en ejecución en un sistema Windows.  Para ello se puede emplear  el plugin  check_winprocess  ( https://www.itefix.no/i2/check_winprocess  ) creado por la empresa Itefix.   Se trata de un plugin basado en NRPE, aplicación que permite ejecutar remotamente plugins de Nagios en otras máquinas, bajo Linux o bajo Windows.      Para hacer funcionar NRPE en el cliente se ha utilizado NSClient++, concretamente la versión 0.3.9 : http://sourceforge.net/projects/nscplus/files/nscplus/NSClient%2B%2B%200.3.9/ . La última versión de NSClient++ a fecha de creación de este artículo (0.4.1.73) no funciona correctamente    para nuestro propósito.    Una vez instalado NSClient++ (marcar como mínimo  check_nrpe  en el proceso de instalación) deberemos copiar el ejecutable  check_winprocess.exe  dentro del directorio  scripts de NSClien

/bin    :aqui estan todos los comandos importantes de la consola de Linux. $tail -F /../../syslog.glog | grep juan > fichero --> mira en la cola del fichero syslog.log buscando el texto juan y lo deja en un fichero llamado "fichero"  $df -h    ------> mirar el espacio en las unidades del sistema $du -h ---> nos dice que pesa cada carpeta y espacio en kb, mb que usa $tar cvzf /var/log/backup.tgz /etc/home/ ----->crear ficheros comprimidos $ tar xzvf xxx.tgz ...     ----------> descomprimir ficheros $cat /var/log/syslog | grep error | wc -l    -----> Mirar los logs y saca solo aquellos que tengan la palabra "Error" $top ---> para mirar el rendimiento en linux(uso de cpu, procesos en ejecución, memoria libre, etc ...) $ps aux ---> lista todos los procesos en ejecución del sistema $ps aux | grep java --> lista solo los procesos que contengan el literal java $kill -9 "proceso por pid" --> paramos el pro