Montar particion o disco usb con formato ntfs en centos 6.x

Descargar rpmforge

wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

Instalar el paquete

rpm -Uvh rpmforge-release-0.3.6-1.el5.rf.i386.rpm

Instalar los paquetes para ntfs

yum install fuse fuse-ntfs-3g dkms dkms-fuse

Montar el disco usb o la partición (primera línea ejemplo disco usb la segunda una partición)

mount -t ntfs-3g /dev/disk/by-uuid/1ADC8962DC893951 /media/wd

mount -t ntfs-3g /dev/hdc1 /mnt/datos

Fuente: http://www.lemursolution.com/node/55

Guardar reglas iptables de forma permanente - Raspbian

Guardamos el fichero "iptables" con las reglas de iptables por ejemplo en la ruta: /etc/network/iptables

Añadimos la siguiente línea en el archivo /etc/network/interfaces al final de la sección eth0, no al final del archivo.

post-up iptables-restore < /etc/network/iptables

Fuentes:http://www.cyberciti.biz/faq/how-do-i-save-iptables-rules-or-settings/

Enviar correos con POSTFIX haciendo relay con una cuenta de GMail

Necesitaba que las alertas de Fail2ban me llegaran a mi cuenta de correo de GMail. Para ello podemos configurar POSTFIX para que haga relay al servidor de GMail utilizando una cuenta que tengamos en Gmail.

Creamos el siguiente fichero con el usuario y contraseña de nuestra cuenta de gmail

echo "smtp.gmail.com smtp_user:smtp_passwd" > /etc/postfix/sasl_passwd

Para evitar que sea legible el usuario y contraseña hacemos lo siguiente. Se genera el fichero sasl_passwd.db. Una vez se compruebe que funciona el fichero sasl_passwd lo borramos.

postmap hash:/etc/postfix/sasl_passwd

Editamos el fichero /etc/postfix/main.cf y añadimos los siguiente al principio. Asumimos que tenemos el certificado /etc/pki/tls/certs/ca-bundle.crt. Este se crea con la instalación de openssl. En una instalación de CentOS 6.5 basic server ya está instalado.

#Set the relayhost to the Gmail SMTP server 
relayhost = smtp.gmail.com:587 
#Set the required TLS options 
smtp_tls_security_level = secure 
smtp_tls_mandatory_protocols = TLSv1 
smtp_tls_mandatory_ciphers = high 
smtp_tls_secure_cert_match = nexthop 
#Check that this path exists -- these are the certificates used by TLS smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt 
#Set the sasl options 
smtp_sasl_auth_enable = yes 
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous

Reiniciamos el servicio postfix

service postfix restart

Probamos que funciona

echo “pruebas” | mail –s “pruebas” user@example.com

Para gestionar la cola de correos de postfix /mailq, Esta pequeña guía:
http://blog.kvs-solutions.com/?p=557

Un detalle importante es que puede dar problemas la configuración de gmail. Parece ser que ahora es más exigente con la seguridad y es posible que si no haces lo siguiente no funcione:

En la configuración de la cuenta en inicio donde cambiamos la contraseña de la cuenta hay un apartado que dice "Acceso de aplicaciones menos seguras" por defecto está bloqueado. En el caso de no funcionar antes de nada probar a desbloquear esta opción, y descartar que no sea esto. No tengo claro que sucede al desbloquear esto.

Otro detalle es que posiblemente al hacer el shudown del servidor entre el stop del demonio fail2ban y el de postfix no de tiempo a enviar los correos que advierten de la detención de las distintas "jail" configuradas en fail2ban enviándolos en el siguiente inicio pudiendo provocar confusiones en el funcionamiento. Para solucionarlo en /etc/init.d tenemos el script de inicio y apagado (fail2ban) añadimos un retraso en el apagado de unos segundos para que de tiempo a enviar los correos (p.e. sleep 30).

. . . 
stop() { 
   echo -n $"Stopping fail2ban: " 
   # Retrasa la detención de postfix para que de tiempo a enviar los correos con la alertas de fail2ban 
   sleep 30 
   # 
   ${FAIL2BAN} stop > /dev/null 
   RETVAL=$? 
   if [ $RETVAL = 0 ]; then 
      rm -f ${lockfile} ${pidfile} 
      echo_success 
   else 
      echo_failure 
   fi 
   echo 
   return $RETVAL 
   } 
. . .

fail2ban y owncloud

Estos son los pasos a seguir para configurar fail2ban y owncloud de manera que cuando se produzcan errores en el login se produzca el baneo de la ip presuntamente atacante. Partiendo de la base de que tenemos instalado y funcionando file2ban.

Editamos el fichero de configuración config.php situado en el directorio data de la instalación de owncloud y añadimos la siguientes líneas.

'logtimezone' => 'Europe/Madrid',
'logfile' => '/var/log/owncloud.log',
'loglevel' => '2',
'log_authfailip' => true,

Creamos el siguiente filtro para file2ban en esta ruta: /etc/fail2ban/filter.d/owncloud.conf
(Este filtro está probado con la versión 7.0.4 de owncloud)

[Definition]
failregex={"app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"}

ignoreregex =

(Este filtro está probado con la versión 8.0.3.4 de owncloud)

[Definition]
failregex= {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"}

ignoreregex =

(Este filtro está probado con la versión 8.1.0 de owncloud)

[Definition]
failregex={"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '\)","level":2,"time":".*"}

ignoreregex =

Editamos el fichero /etc/fail2ban/jail.local y añadimos lo siguiente

[owncloud]
enabled = true
filter  = owncloud
action  = iptables-multiport[name=owncloud,port="80,443"]
logpath = /var/log/owncloud.log

Creamos el fichero /var/log/owncloud.log y le hacemos propietario al usuario "daemon" y el grupo "daemon"

Podemos probar si la expresión regular es correcta y asegurarnos de que funcionará el filtro con el siguiente comando.

fail2ban-regex /var/www/owncloud/data/owncloud.log /etc/fail2ban/filter.d/owncloud.conf -v

Reiniciamos fail2ban y ya podemos probar que funciona. Dependiendo de como tengamos la configuración general de fail2ban a los tres intentos en mi caso queda bloqueada la ip que ha intentado logearse incorrectamente.

Fuente:  http://www.rojtberg.net/711/secure-owncloud-server/ (tiene algunos fallos que se solucionan en este post)
regex para la versión 8.0.x.x. : https://forum.owncloud.org/viewtopic.php?f=31&t=26336
regex para la versión 8.1.0: https://forum.owncloud.org/viewtopic.php?f=8&t=28678 

Crear un lanzador en el escritorio de ubuntu

gnome-desktop-item-edit ~/Escritorio --create-new

Montar unidad owncloud con davfs2 y Ubuntu 14.04

1. Instalamos davfs2

sudo apt-get install davfs2

2. Reconfigurar davfs2

sudo dpkg-reconfigure davfs2

3. Añadir nuestro usuario al grupo davfs2

sudo usermod -aG davfs2 <user>

4. Añadir la siguiente línea a /etc/fstab

https://mi.dominio/owncloud/remote.php/webdav/ /home/usuario/owncloud davfs user,rw,noauto 0 0

 Para cada usuario que quiera montar la carpeta:

En su home creamos las carpetas /owncloud y /.davfs2/

Dentro de .davfs2 creamos el archivo secrets con la siguiente línea

https://mi.dominio/owncloud/remote.php/webdav/ <usuario> "<contraseña>"

(La contraseña debe ir entre comillas) 

Cambiamos permisos

chmod 600 ~/.davfs2/secrets

Ejecutamos el comando

mount ~/owncloud

Si usamos un certificado self signed y queremos evitar la advertencia

echo "y" | mount ~/owncloud > /dev/null 2>&1

Ajustes en el fichero de configuración davfs2.conf.

Hay dos ficheros de configuración uno en /etc/davfs2/ y otro que hemos creado para cada usuario en la carpeta .davfs2/ dentro del home. Primero toma la configuración del que está en /etc/ y luego la configuración del que está en el home.

use_locks 0

Este ajuste me dió muchos problemas hasta que lo configuré, sin él las conexiones webdav al servidor owncloud eran inestables y sobre todo no se podían copiar archivos de gran tamaño.

use_expect100 1

Otro de las modificaciones fue el cache size, aunque no sé si influye. No lo he comprobado.

cache_size   6144

Nota:

El montar unidades con davfs2 es un poco peculiar y tiene un comportamiento que se presta ser interpretado como que funciona mal. No se trata de una conexión síncrona, es decir, cuando hacemos una copia primero se transfiere a una caché. Este paso es el que vemos que va rápido luego aparentemente se queda parado y es el momento en el que si no lo sabes crees que no funciona. Pero si que funciona. En este momento empieza la transferencia real de la caché al servidor remoto y tarda lo que tenga que tardar, sin ofrecer información de progreso. Es importante la opción de la configuración "use_expect100  1", sin ella el funcionamiento es caótico con el servidor owncloud.

Como curiosidad con clientes windows he utilizado  NetDrive, es de pago pero cuando termina el trial en principio puedes seguir utilizándolo con alguna limitación. El funcionamiento de Netdrive es muy bueno y no tiene los inconvenientes de davfs2. Aparentemente no hay ninguna diferencia con una conexión CIFS.

Fuentes:
http://doc.owncloud.org/server/6.0/user_manual/files/files.html
http://www.canarytek.com/tutoriales/webdav

uvcvideo: Failed to initialized the device (-5) y Raw EDID

Recién instalado el ubuntu 14.04 al arrancar aparecen los mensajes siguiente no son errores pero algo no va bien. El sistema inicia correctamente a pesar del los mensajes. 

Para solucionar las dos últimas líneas lo encontré en este enlace:
http://crunchbang.org/forums/viewtopic.php?id=19337

sudo apt-get install libglib2.0-dev libusb-dev build-essential gcc automake mercurial

hg clone http://bitbucket.org/ahixon/r5u87x/

cd r5u87x

make

sudo make install

sudo reboot

Para solucionar lo del Raw EDID, no sé bien como lo solucioné pero los pasos fueron seguir los puntos del 1 al 5 del siguiente enlace.
 http://askubuntu.com/questions/201081/how-can-i-make-linux-behave-better-when-edid-is-unavailable
 Que no sirvieron de nada más que para dar errores de boot. El caso es que me había guardado una copia del fichero grub que había modificado. Borré el modificado y renombre de nuevo el grub para dejarlo como estaba, hice sudo grup-update , reboot y cuando arrancó ya no tenía ningún mensaje de error.
Supongo que la solución fué reescribir el grub pero no lo he podido comprobar ya que se solucionó. 

Se ha quedado sin solucionar lo del Raw EDID