viernes, 2 de octubre de 2015

owncloud pdf sin imágenes

El problema se plantea cuando al abrir un pdf desde owncloud utilizando el pdfviewer (app que tenemos activada por defecto) vemos que las imágenes insertadas en el pdf (jpg) aparecen como marcos en blanco. Esto hasta la versión 8.1 se resuelve editando el fichero /var/www/htdocs/owncloud/apps/files_pdfviewer/tests/bootstrap.php y modificándolo añadiendo las líneas en rojo. Con esto se soluciona para chrome, para firefox no.


global $RUNTIME_NOAPPS;
$RUNTIME_NOAPPS = true;

if (!defined('PHPUNIT_RUN')) {
define('PHPUNIT_RUN', 1);
}

require_once __DIR__.'/../../../lib/base.php';

\OC::$loader->addValidRoot(\OC::$SERVERROOT . '/tests');
+\OC_App::loadApp('files_pdfviewer');


if(!class_exists('PHPUnit_Framework_TestCase')) {
require_once('PHPUnit/Autoload.php');
}

OC_Hook::clear();
OC_Log::$enabled = false;

Con la versión 8.1.3 me descargué el pdfviewer  de aquí ya que con el que viene con la actualización no me funcionaba el chrome tampoco. Con esta si que funciona el chrome, se ven las imágenes jpg de los pdf.
Para el firefox de momento creo que no hay solución, solo deshabilitar el csp en la configuración about:config buscar security.csp.enabled y ponerlo a false.

Fuentes:
https://github.com/owncloud/files_pdfviewer/pull/65
https://github.com/owncloud/files_pdfviewer/issues/60

jueves, 10 de septiembre de 2015

iptables: Banear ips automaticamente con lista

Esta es una solución sencilla para tener una lista de ips baneadas que podemos administrar fácilmente.
Hay soluciones más complejas y avanzadas como esta. Yo he optado por la más simple ya que de momento el volumen de ataques no es demasiado alto.
Esta solución la he sacado de este enlace el script esta explicado muy bien. Tiene algún fallito. falta declarar la variable TEMP y falta poner el parametro "-f" en el comando cp de la función unban. Este es el script tal y como yo lo estoy utilizando.

Creamos la carpeta /etc/myOwnFirewall y el script myOwnFirewall dentro de ella

mkdir /etc/myOwnFirewall
vi /etc/myOwnFirewall/myOwnFirewall


El contenido del script sería el siguiente

#!/bin/bash

# myOwnFirewall v0.1
#
# Script para banear IPs
#
# Author: Rolando Caldas
# http://rolandocaldas.com
#
# https://github.com/rolando-caldas/myOwnFirewall

BANNED_IPS="/etc/myOwnFirewall/banList.txt"
LOCK="/etc/myOwnFirewall/.lock"
TEMP="/etc/myOwnFirewall/temp"

function banIP {
        if [ -f ${LOCK} ]
        then
                if [ $# -eq 0 ]
                then
                        echo "You must enter an ip address"
                else
                        ip=$1
                        exists=false
                        for i in `cat $BANNED_IPS`; do
                                if [ $i = $ip ]
                                then
                                        exists=true
                                fi
                        done

                        if [ $exists = false ]
                        then
                                echo $ip >> $BANNED_IPS
                                iptables -I INPUT -s $ip -j DROP
                                iptables -I OUTPUT -s $ip -j DROP
                                echo "IP ${ip} banned"
                        else
                                echo "IP ${ip} already in the list"
                        fi
                fi
        else
                echo "myOwnFirewall is not running"
        fi
}

function restartScript {
        stopScript
        startScript
}

function showHelp {
        echo "Usage: myOwnFirewall {start|stop|restart}"
}

function startScript {

        if [ -f ${LOCK} ]
        then
                echo "myOwnFirewall is already running"
                exit
        else
                ` > ${LOCK}`

                for i in `cat $BANNED_IPS`; do
                        iptables -I INPUT -s $i -j DROP
                        iptables -I OUTPUT -s $i -j DROP
                done

                echo "myOwnFirewall started"
        fi

}

function stopScript {
        if [ -f ${LOCK} ]
        then
                for i in `cat $BANNED_IPS`; do
                        iptables -D INPUT -s $i -j DROP
                        iptables -D OUTPUT -s $i -j DROP
                done
                rm ${LOCK}

                echo "myOwnFirewall stopped"
        else
                echo "myOwnFirewall is not running"
        fi
}

function unbanIP {
        if [ -f ${LOCK} ]
        then
                if [ $# -eq 0 ]
                then
                        echo "You must enter an ip address*"
                else
                        ip=$1
                        exists=false

                        for i in `cat $BANNED_IPS`; do
                                if [ $i = $ip ]
                                then
                                        exists=true
                                else
                                        echo $i >> $TEMP
                                fi
                        done

                        if [ $exists = false ]
                        then
                                echo "IP ${ip} doesn't in the list"
                        else
                                cp -f $TEMP $BANNED_IPS && rm $TEMP
                                iptables -D INPUT -s $ip -j DROP
                                iptables -D OUTPUT -s $ip -j DROP
                                echo "IP ${ip} unbanned"
                        fi
                fi
        else
                echo "myOwnFirewall is not running"
        fi
}

case "$1" in
        ban)
                banIP $2
                exit
                ;;
        restart)
                restartScript
                exit
                ;;
        start)
                startScript
                exit
                ;;
        stop)
                stopScript
                exit
                ;;
        unban)
                unbanIP $2
                exit
                ;;
        *)
                showHelp
                exit
                ;;
esac


En centos y redhat es algo distinto a debian el funcionamiento de iptables los cambios en las reglas no se guardan a no ser que lo forcemos con "service iptables save".
Yo no me he complicado mucho y ejecuto el script con el parámetro start en el inicio del sistema en el rc.local y borro el fichero .lock en el shutdown. He aprovechado el script de iptables en el init.d y he añadido la línea rm -f /etc/myOwnFirewall/.lock en la función stop(). De este modo cuando se detiene el servicio iptables borra el fichero .lock que le sirve al script para saber si el baneado de ips está activo.
El funcionamiento del script está muy bien explicado en este enlace

jueves, 3 de septiembre de 2015

Apache: baneo de ips por códigos de error y palabras clave.

Este "jail" es sencillo y efectivo permite banear las ips en el momento aparece en el log de accesos de apache alguno de los códigos de error que especificamos en el "failregex" del filtro.
Es necesario incluir en "ignoreregex" las palabras clave de aquellos falsos ataques, errores que provoca por ejemplo owncloud con las subidas de instantáneas (cuando tenemos sincronizado nuestro android para que suba las fotos automáticamente).
Añadimos las siguientes líneas al archivo de conguración jail.local

[apache-misc]
enabled = true
filter = apache-misc
action = iptables-multiport[name=apache-misc,port="80,443"]
sendmail-whois[name=apache-misc, dest=alertas@micorreo.com, sender=alertas@micorreo.com, sendername="Fail2Ban"]
logpath = /opt/lampp/logs/access_log
maxretry = 1

maxretry: Especifica cuantos intentos vamos a dejar antes de banear la ip.

Ahora creamos el archivo de filtrado en /etc/fail2ban/filters.d/apache-misc.conf y dentro de el colocamos el siguiente contenido:

[Definition]
failregex = .*"[A-Z]* /(cms|user|muieblackcat|db|cpcommerce|wp-login|joomla|awstatstotals|wp-content|wp-includes|pma|phpmyadmin|myadmin|mysql|mysqladmin|sqladmin|mypma|admin|xampp|mysqldb|pmadb|phpmyadmin1|phpmyadmin2).*"
.*\" (502|500|417|416|415|414|413|412|404|405|403|401|400)
ignoreregex = .*\"GET \/.*(ciruela|press|mailto|domestic|word|externalShares).*
.*\"HEAD \/.*SubidasInstant.*
.*\"GET \/.*SubidasInstant.*

Todas estas palabras clave son a modo de ejemplo. Son las que podría un atacante intentar localizar.
Lo que si me ha funcionado son las dos últimas líneas para evitar los falsos errores 404 que provocaba owncloud.

Reiniciamos fail2ban

service fail2ban restart

Fuente:http://www.linux-magazine.com/Online/Features/Intrusion-Detection-with-fail2ban

Apache: mitigando ataque DOS con fail2ban

Básicamente configurando de este modo fail2ban conseguimos parar a un atacante que haga exageradas peticiones GET o POST que podrían dejar frito nuestro servidor. Añadimos las siguientes líneas al archivo de conguración jail.local

[http-dos]
enabled = true
filter = http-dos
action = iptables-multiport[name=http-dos,port="80,443"]
sendmail-whois[name=http-dos, dest=alertas@micorreo.com, sender=alertas@micorreo.com, sendername="Fail2Ban"]
logpath = /opt/lampp/logs/access_log
maxretry = 300
findtime = 300
bantime = 300

maxretry: Especifica cuantos intentos vamos a dejar antes de banear la ip.
findtime: Es el período de tiempo en segundos que estamos contando los “reintentos” (300 segundos = 5 minutos).
bantime: Es el tiempo que debemos esperar para liberar las peticiones, osea el tiempo que la IP estará baneada, en este caso se trata de 5 minutos.

Ahora creamos el archivo de filtrado en /etc/fail2ban/filters.d/http-dos.conf y dentro de el colocamos el siguiente contenido:

[Definition]
failregex = .*\"(GET|POST).*
ignoreregex =

Reiniciamos fail2ban

service fail2ban restart

Una manera sencilla de comprobar el funcionamiento de nuestra configuración anterior es utilizando ab (Apache Benchmark - parte del paquete apache2-utils) , así:

ab -n 500 -c 10 http://tu-sitio-web-punto-com:80/

Fuente:http://rootear.com/seguridad/mitigar-ataques-ddos-fail2ban

miércoles, 12 de agosto de 2015

Owncloud - The "Strict-Transport-Security" HTTP header is not configured . . .

Editamos httpd.conf. Con este Header el servidor web informa a los navegadores que nunca cargue una página utilizando http. Deben cagar páginas solo como https

Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

Para redireccionar los accesos http a https

<VirtualHost *:80>
   ServerName localhost
   Redirect permanent / https://mi.url/
</VirtualHost>,

Fuente: https://doc.owncloud.org/server/8.1/admin_manual/configuration_server/harden_server.html

martes, 11 de agosto de 2015

Owncloud - No memory cache has been configured. To enhance your performance please configure a memcache if available

En este enlace esta explicado con detalle. En mi caso tenía instalado php 5.5 y añadí la siguiente línea en el el config.php de owncloud

'memcache.local' => '\OC\Memcache\APCu',

Owncloud - This server has no working Internet connection . . .

Después de instalar owncloud 8.1 en centos 6.6 aparece este mensaje en la pantalla de configuración.

"This server has no working Internet connection. This means that some of the features like mounting external storage, notifications about updates or installation of third-party apps will not work. Accessing files remotely and sending of notification emails might not work, either. We suggest to enable Internet connection for this server if you want to have all features"

Esta solución puede ser válida también para Centos 7 con el repositorio adecuado, indicado en el enlace adjunto (yo no lo he probado con Centos 7).

En este enlace está la solución (post de: maelange commented . Yo lo he comprobado con centos 6.6 y ha funcionado.
Al parecer es la libreria libcurl que está obsoleta. El error tiene que ver con que esta librería utiliza ssl3 en lugar de tls.
para ver  la versión que tenemos instalada

curl -V

Solución:

rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-1-13.rhel6.noarch.rpm
yum install libcurl

Ahora ya no dará el error y podemos comprobar que la librería libcurl se ha actualizado.


viernes, 7 de agosto de 2015

Instalar owncloud 8.x en centos 6.x desde repositorio

Owncloud recomienda la instalación desde los repositorios. Se garantizan las actualizaciones automáticas cuando se actualiza el sistema operativo.

He seguido varios tutoriales y esta guía es un mezcladillo. Tenemos que instalar el servidor apache con php 5.5 y el servidor mysql. Luego se añaden los repositorios necesarios para instalar owncloud y se instala.

Primero instalamos el servidor web apache

Añadimos el nombre del Host a /etc/hosts

vi /etc/hosts

Añadimos esta línea

127.0.0.1 OWNCLOUD # nombre del servidor

Editamos /etc/sysconfig/network

vi /etc/sysconfig/network
.
Editamos /etc/sysconfig/network

NETWORKING=yes
HOSTNAME=OWNCLOUD

Actualizamos el sistema

yum update

Si queremos que al instalar los grupos, que veremos mas adelante, se instalen también los paquetes opcionales, añadiremos entonces en el fichero "/etc/yum.conf" la siguiente línea:

group_package_types=mandatory,default,optional

Seguimos instalando:

yum install gcc make kernel-devel perl
.
Seguimos instalando:

yum groupinstall “Development tools”
.
Instalamos PHP

yum groupinstall "PHP Support”

yum install php-mbstring php-devel php-mcrypt zlib zlib-devel zlib-static
.
Editamos /etc/php.ini y añadimos la siguiente línea

date.timezone = "Europe/Madrid"
.
Instalamos las librerías de desarrollo
.
yum install httpd-devel
.
Comprobamos la versión de apache
.
httpd -v
.
Comprobamos la versión de php
.
php -v
.
Debemos tener instalado mínimo php 5.5 (creo que 5.4 también vale /??)
En caso de tener que actualizar en esta web lo explica (yo actualicé siguiendo estos pasos)
http://www.servermom.org/upgrade-php-53-54-55-centos/1534/
.
Editamos el fichero /etc/httpd/conf /httpd.conf, debe aparecer la siguiente línea.
.
ServerName localhost

Eliminamos la página de bienvenida de apache. Editamos el fichero /etc/httpd/ conf.d/welcome.conf y comentamos todas la líneas.
.
#
# This configuration file enables the default "Welcome"
# page if there is no default index page present for
# the root URL. To disable the Welcome page, comment
# out all the lines below.
#
#
# Options -Indexes
# ErrorDocument 403 /error/noindex.html
#


Iniciamos apache
.
service httpd start
.
Lo configuramos para que siempre arranque apache en el inicio del sistema operativo.
.
chkconfig httpd on
.
Ahora instalamos Mysql

Instalamos  el servidor Mysql

yum groupinstall “MySQL Database server”
.
Instalamos el cliente Mysql

yum groupinstall “MySQL Database client”
.
Iniciamos Mysql

service mysqld start
.
Hacemos segura la instalación del servidor Mysql

/usr/bin/mysql_secure_installation
.
Para que se inicie al arrancar el sistema

chkconfig mysqld on
.
Si queremos comprobar los servicios que arrancan con el inicio del sistema.

chkconfig --list
.
Creamos la base de datos de owncloud y otorgamos permisos a un usuario

mysql -uroot -p
CREATE DATABASE owncloud; GRANT ALL PRIVILEGES ON owncloud.* TO 'owncloud_user'@'localhost' IDENTIFIED BY 'owncloud_user_pasword'; FLUSH PRIVILEGES;
.
Ahora instalamos Owncloud

cd /etc/yum.repos.d/
wget http://download.opensuse.org/repositories/isv:ownCloud:community/CentOS_CentOS-6/isv:ownCloud:community.repo

rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

yum install owncloud
.
Ahora solo queda acceder con un navegador a la ip_del_servidor/owncloud y seguir los pasos de configuración que son: elegir el tipo de base de datos que será mysql, el nombre de la base de datos, el usuario y la contraseña.

Fuentes:
https://www.howtoforge.com/how-to-install-owncloud_7-on-centos_6.5
http://www.desarrolloweb.com/articulos/configuracion-servidor-web-centos.html




jueves, 6 de agosto de 2015

La red no funciona después de clonar una máquina CentOS en vmware

Vmware cuando clona una máquina le asigna una nueva mac a las nic (tarjetas de red). Por este motivo con la configuación de networking que trae la máquina clonada no funciona la red. Para solucionarlo tenemos que saber las nuevas macs asignadas por vmware, para ello vamos a edit setings de la máquina en cuestión y en los adaptadores podemos consultar la nueva mac.
Ahora toca modificar la configuración de la máquina clonada:

1. Editamos  /etc/sysconfig/network-scripts/ifcfg-eth0 y sustituimos la mac antigua por la nueva. En el caso de existir el parámetro uuid, yo lo eliminé. Existe un comando para generar uuids nuevos para las nic "uuidgen eth0" pero yo preferí eliminarlo. Con la mac creo que es suficiente.

2. Editamos /etc/udev/rules.d/70-persistent-net.rules y modificamos la mac antigua por la nueva eliminando las entradas que no correspondan. Se habrán quedado nuevos interfaces eth1, eth2, etc. Dejar solo el que correspondan con la mac nueva.

3. Yo reinicié la máquina, en las web que he consultado dicen de ejecutar "ifup eth0"

Fuente: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2002767


domingo, 28 de junio de 2015

Configurar red en Raspbian sin interfaz gráfica.

Editar /etc/network/interfaces
la siguiente configuración puede ser un ejemplo.

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.105
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1
dns-nameservers 8.8.8.8 8.8.4.4


Reiniciar los servicios de red

/etc/init.d/networking restart 


Fuentes:
https://www.raspberrypi.org/forums/viewtopic.php?t=23127
http://es.ccm.net/faq/3282-reiniciar-la-interfaz-de-red-en-linea-de-comandos

sábado, 2 de mayo de 2015

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

domingo, 15 de marzo de 2015

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/

domingo, 15 de febrero de 2015

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 
   } 
. . .


domingo, 8 de febrero de 2015

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 

domingo, 4 de enero de 2015

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