Permisos en DocumentRoot apache al trabajar otros usuarios

2014-04-30 Por tema Maykel Franco
Hola buenas, creo que se ha comentado alguna vez en esta lista la
consulta que voy hacer, pero no encuentro el hilo...

El caso es que tengo un Apache sobre Debian con DocumentRoot por
defecto en /var/ww. El caso es que varios programadores, desarrollan y
suben contenido a directorios que se encuentran dentro de /var/www/.

El problema es cuando suben el código con un usuario, se sube
evidentemente con permisos de usuario y de grupo, de la persona que lo
ha subido por sftp. Pero sin permisos de escritura para el grupo y
para otros usuarios. Con lo cual el usuario apache, www-data en este
caso, no va a poder realizar operaciones de escritura...

Esto lo tengo solventado de tal forma que los programadores que
suben el código, les tengo agregados al grupo de apache www-data.

Pero aún así, tengo que realizar manualmente un chown -R
usuario:www-data y además, chmod -R g+w .

Cómo podría automatizar esto, más bien dejarlo permanente, para que
cuando suban código apache tenga permisos de
lectura/escritura/ejecución...

Se me ocurren un par de opciones:

1- Se da contraseña al usuario www-data para que los usuarios usen ese
usuario para subir. (no me parece seguro abrir el usuario apache por
ssh)

2- Se elemina el grupo por defecto de cada usuario que genra
automáticamente, y se le pone por defecto el grupo de apache, y se
cambia el umask de manera permanente a 002

Alguna sugerencia?

Gracias de antemano.

Saludos.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caj2aoa_pvsw5a_oj3jgk_qn_4day8bb-aaikgwmsfkf2c9d...@mail.gmail.com



Re: Permisos en DocumentRoot apache al trabajar otros usuarios

2014-04-30 Por tema Juan Guil
 Hola buenas, creo que se ha comentado alguna vez en esta lista la
 consulta que voy hacer, pero no encuentro el hilo...

 El caso es que tengo un Apache sobre Debian con DocumentRoot por
 defecto en /var/ww. El caso es que varios programadores, desarrollan y
 suben contenido a directorios que se encuentran dentro de /var/www/.

 El problema es cuando suben el código con un usuario, se sube
 evidentemente con permisos de usuario y de grupo, de la persona que lo
 ha subido por sftp. Pero sin permisos de escritura para el grupo y
 para otros usuarios. Con lo cual el usuario apache, www-data en este
 caso, no va a poder realizar operaciones de escritura...

 Esto lo tengo solventado de tal forma que los programadores que
 suben el código, les tengo agregados al grupo de apache www-data.

 Pero aún así, tengo que realizar manualmente un chown -R
 usuario:www-data y además, chmod -R g+w .

 Cómo podría automatizar esto, más bien dejarlo permanente, para que
 cuando suban código apache tenga permisos de
 lectura/escritura/ejecución...

 Se me ocurren un par de opciones:

 1- Se da contraseña al usuario www-data para que los usuarios usen ese
 usuario para subir. (no me parece seguro abrir el usuario apache por
 ssh)

 2- Se elemina el grupo por defecto de cada usuario que genra
 automáticamente, y se le pone por defecto el grupo de apache, y se
 cambia el umask de manera permanente a 002

 Alguna sugerencia?

 Gracias de antemano.

 Saludos.


Hola.
Personalmente haria la segunda opcion, para agregar nuevos usuarios en
linux es con el comando adduser. Para cambiarle la configuracion por
defecto lo puedes hacer con el fichero /etc/adduser.conf, aqui puedes
cambiarle la  mask como van a escribir, y el grupo por defecto que va
a tener, los usuarios que ya tienes creados, ya te toca modificarlos a
mano
Mas informacion la tienes en:

http://manpages.ubuntu.com/manpages/dapper/es/man5/adduser.conf.5.html

Un saludo


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/camf5f5c_op9a8158xvdqebambdekqfirrc43dgc14f2os0t...@mail.gmail.com



Re: OT: Muy OT: Clamav -Immunet

2014-04-30 Por tema Ricardo Delgado

 Yo no recomendaría ClamAV para Windows, hay mejores opciones y por
 mejores quiero decir soluciones con mayor índice de detección de malware.



ClamAV para Windows siempre estuve recomendando, para aquellos que me
consultaban por un Antivirus,

Lo hago por lo siguiente

* funciona en Debian
* es GPL

Y siempre que puedo sugiero para los usuarios de Windows soft que sea
Libre, esto a quienes no quieren dejar W$ y tampoco hacer de soporte
de MS

Mirare que alternativas de AV libres hay para W$, asi cambio mis
sugerencias para el proximo.

Gracias


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+0kpa0d_we5ncx-k28arusacdiqka6odsp7assfhpoedpe...@mail.gmail.com



Re: OT: Muy OT: Clamav -Immunet

2014-04-30 Por tema Roberto Quiñones
El día 30 de abril de 2014, 9:28, Ricardo Delgado
ricardodelgad...@gmail.com escribió:

 Yo no recomendaría ClamAV para Windows, hay mejores opciones y por
 mejores quiero decir soluciones con mayor índice de detección de malware.



 ClamAV para Windows siempre estuve recomendando, para aquellos que me
 consultaban por un Antivirus,

 Lo hago por lo siguiente

 * funciona en Debian
 * es GPL

 Y siempre que puedo sugiero para los usuarios de Windows soft que sea
 Libre, esto a quienes no quieren dejar W$ y tampoco hacer de soporte
 de MS

 Mirare que alternativas de AV libres hay para W$, asi cambio mis
 sugerencias para el proximo.

 Gracias


 --
 To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/ca+0kpa0d_we5ncx-k28arusacdiqka6odsp7assfhpoedpe...@mail.gmail.com


Existe un antivirus [1] al igual que ClamWin, utiliza el motor de
ClamAV y lo mejor a ClamWin es que si viene con protección en tiempo
real, cosa que hoy en día se necesita mucho en equipos de escritorio
basados en Windows.

[1] http://www.moonsecure.com/

Saludos
-- 

Roberto Quiñones

Owner - Service Manager and System
ACShell.NET – Internet Services
robe...@acshell.net - www.acshell.net
San Martin #311 Santiago – CL (Chile)
+560981361713



--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cao7f6e-pmxirozwss++hct2yralt809gg0saxk1j9n0fxlb...@mail.gmail.com



Re: [OT] Re: Problemas Nat Asterisk en Debian atravesando 2 firewall

2014-04-30 Por tema Maykel Franco
El día 24 de abril de 2014, 15:44, Camaleón noela...@gmail.com escribió:
 El Thu, 24 Apr 2014 10:17:51 +0200, Maykel Franco escribió:

 Hola buenas, tengo un servidor asterisk bajo debian. En la misma red
 funciona perfecto e incluso en otra red que pasa por el mismo firewall
 también funciona.

 El problema viene cuando se realizan llamadas atravesando 2 firewall(2
 nat), que no se escucha la voz...Según he estado mirando en internet
 puede deberse a que necesite utilizar stun.

 Uso puertos por defecto 5060 para registro de los clientes y 1:2
 para streaming de voz.

 Alguien ha tenido problemas con asterisk en debian atravesando por
 varios firewall?

 Que la santa espiral te asista, amigo :-)

 Vas a tener que hilar fino, fino para ajustar los cortafuegos con el voip,
 yo me las veo y me las deseo con los terminales Cisco SPA5xx (hay varios
 terminales con varias extensiones registradas...) y eso que sólo hay un
 cortafuegos y un NAT de por medio.

 Al final tuve que llegar a un consenso: unos terminales usan servidores
 STUN y otros están configurados para hacer NAT traversal con reenvío de
 puerto.

 Saludos,

 --
 Camaleón


 --
 To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/pan.2014.04.24.13.44...@gmail.com



Gracias por contestar Camaleón.

Y otra cosa, el servidor stun tiene que estar en el mismo firewall
donde tienes nateado el puerto 5060 de registro y el de streaming
1:2? O el servidor stun puede estar en otro firewall que no
sea ese?

Imaginaros que el firewall por donde pasa el tráfico de asterisk no
tenga para montar un servidor stun...

Saludos y gracias como siempre.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJ2aOA9qLC4MZc=nf+drifz34cf12t5crpmut-834-ggo...@mail.gmail.com



Re: Permisos en DocumentRoot apache al trabajar otros usuarios

2014-04-30 Por tema Maykel Franco
El día 30 de abril de 2014, 14:38, Juan Guil erj...@gmail.com escribió:
 Hola buenas, creo que se ha comentado alguna vez en esta lista la
 consulta que voy hacer, pero no encuentro el hilo...

 El caso es que tengo un Apache sobre Debian con DocumentRoot por
 defecto en /var/ww. El caso es que varios programadores, desarrollan y
 suben contenido a directorios que se encuentran dentro de /var/www/.

 El problema es cuando suben el código con un usuario, se sube
 evidentemente con permisos de usuario y de grupo, de la persona que lo
 ha subido por sftp. Pero sin permisos de escritura para el grupo y
 para otros usuarios. Con lo cual el usuario apache, www-data en este
 caso, no va a poder realizar operaciones de escritura...

 Esto lo tengo solventado de tal forma que los programadores que
 suben el código, les tengo agregados al grupo de apache www-data.

 Pero aún así, tengo que realizar manualmente un chown -R
 usuario:www-data y además, chmod -R g+w .

 Cómo podría automatizar esto, más bien dejarlo permanente, para que
 cuando suban código apache tenga permisos de
 lectura/escritura/ejecución...

 Se me ocurren un par de opciones:

 1- Se da contraseña al usuario www-data para que los usuarios usen ese
 usuario para subir. (no me parece seguro abrir el usuario apache por
 ssh)

 2- Se elemina el grupo por defecto de cada usuario que genra
 automáticamente, y se le pone por defecto el grupo de apache, y se
 cambia el umask de manera permanente a 002

 Alguna sugerencia?

 Gracias de antemano.

 Saludos.


 Hola.
 Personalmente haria la segunda opcion, para agregar nuevos usuarios en
 linux es con el comando adduser. Para cambiarle la configuracion por
 defecto lo puedes hacer con el fichero /etc/adduser.conf, aqui puedes
 cambiarle la  mask como van a escribir, y el grupo por defecto que va
 a tener, los usuarios que ya tienes creados, ya te toca modificarlos a
 mano
 Mas informacion la tienes en:

 http://manpages.ubuntu.com/manpages/dapper/es/man5/adduser.conf.5.html

 Un saludo


 --
 To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/camf5f5c_op9a8158xvdqebambdekqfirrc43dgc14f2os0t...@mail.gmail.com


Muchas gracias.

Voy a realizar pruebas y comento.

Saludos.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJ2aOA_sfFtirZ=3gzsvmzweqb4mcezdfrw6hmdf_tsb6w2...@mail.gmail.com



Re: Permisos en DocumentRoot apache al trabajar otros usuarios

2014-04-30 Por tema Maykel Franco
El día 30 de abril de 2014, 18:02, Maykel Franco
maykeldeb...@gmail.com escribió:
 El día 30 de abril de 2014, 14:38, Juan Guil erj...@gmail.com escribió:
 Hola buenas, creo que se ha comentado alguna vez en esta lista la
 consulta que voy hacer, pero no encuentro el hilo...

 El caso es que tengo un Apache sobre Debian con DocumentRoot por
 defecto en /var/ww. El caso es que varios programadores, desarrollan y
 suben contenido a directorios que se encuentran dentro de /var/www/.

 El problema es cuando suben el código con un usuario, se sube
 evidentemente con permisos de usuario y de grupo, de la persona que lo
 ha subido por sftp. Pero sin permisos de escritura para el grupo y
 para otros usuarios. Con lo cual el usuario apache, www-data en este
 caso, no va a poder realizar operaciones de escritura...

 Esto lo tengo solventado de tal forma que los programadores que
 suben el código, les tengo agregados al grupo de apache www-data.

 Pero aún así, tengo que realizar manualmente un chown -R
 usuario:www-data y además, chmod -R g+w .

 Cómo podría automatizar esto, más bien dejarlo permanente, para que
 cuando suban código apache tenga permisos de
 lectura/escritura/ejecución...

 Se me ocurren un par de opciones:

 1- Se da contraseña al usuario www-data para que los usuarios usen ese
 usuario para subir. (no me parece seguro abrir el usuario apache por
 ssh)

 2- Se elemina el grupo por defecto de cada usuario que genra
 automáticamente, y se le pone por defecto el grupo de apache, y se
 cambia el umask de manera permanente a 002

 Alguna sugerencia?

 Gracias de antemano.

 Saludos.


 Hola.
 Personalmente haria la segunda opcion, para agregar nuevos usuarios en
 linux es con el comando adduser. Para cambiarle la configuracion por
 defecto lo puedes hacer con el fichero /etc/adduser.conf, aqui puedes
 cambiarle la  mask como van a escribir, y el grupo por defecto que va
 a tener, los usuarios que ya tienes creados, ya te toca modificarlos a
 mano
 Mas informacion la tienes en:

 http://manpages.ubuntu.com/manpages/dapper/es/man5/adduser.conf.5.html

 Un saludo


 --
 To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/camf5f5c_op9a8158xvdqebambdekqfirrc43dgc14f2os0t...@mail.gmail.com


 Muchas gracias.

 Voy a realizar pruebas y comento.

 Saludos.

Lo único que los permisos que hay en /etc/adduser.conf son para la
creación de directorios, pero no sé como se comportará para la
creación de ficheros...

Saludos.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caj2aoa8jyucjw6km6yohwuql33-gabjo9ogugokvn6beq_i...@mail.gmail.com



Re: Permisos en DocumentRoot apache al trabajar otros usuarios

2014-04-30 Por tema Roger Orellana
2014-04-30 10:04 GMT-06:00 Maykel Franco maykeldeb...@gmail.com:

 El día 30 de abril de 2014, 18:02, Maykel Franco
 maykeldeb...@gmail.com escribió:
  El día 30 de abril de 2014, 14:38, Juan Guil erj...@gmail.com
 escribió:
  Hola buenas, creo que se ha comentado alguna vez en esta lista la
  consulta que voy hacer, pero no encuentro el hilo...
 
  El caso es que tengo un Apache sobre Debian con DocumentRoot por
  defecto en /var/ww. El caso es que varios programadores, desarrollan y
  suben contenido a directorios que se encuentran dentro de /var/www/.
 
  El problema es cuando suben el código con un usuario, se sube
  evidentemente con permisos de usuario y de grupo, de la persona que lo
  ha subido por sftp. Pero sin permisos de escritura para el grupo y
  para otros usuarios. Con lo cual el usuario apache, www-data en este
  caso, no va a poder realizar operaciones de escritura...
 
  Esto lo tengo solventado de tal forma que los programadores que
  suben el código, les tengo agregados al grupo de apache www-data.
 
  Pero aún así, tengo que realizar manualmente un chown -R
  usuario:www-data y además, chmod -R g+w .
 
  Cómo podría automatizar esto, más bien dejarlo permanente, para que
  cuando suban código apache tenga permisos de
  lectura/escritura/ejecución...
 
  Se me ocurren un par de opciones:
 
  1- Se da contraseña al usuario www-data para que los usuarios usen ese
  usuario para subir. (no me parece seguro abrir el usuario apache por
  ssh)
 
  2- Se elemina el grupo por defecto de cada usuario que genra
  automáticamente, y se le pone por defecto el grupo de apache, y se
  cambia el umask de manera permanente a 002
 
  Alguna sugerencia?
 
  Gracias de antemano.
 
  Saludos.
 
 
  Hola.
  Personalmente haria la segunda opcion, para agregar nuevos usuarios en
  linux es con el comando adduser. Para cambiarle la configuracion por
  defecto lo puedes hacer con el fichero /etc/adduser.conf, aqui puedes
  cambiarle la  mask como van a escribir, y el grupo por defecto que va
  a tener, los usuarios que ya tienes creados, ya te toca modificarlos a
  mano
  Mas informacion la tienes en:
 
  http://manpages.ubuntu.com/manpages/dapper/es/man5/adduser.conf.5.html
 
  Un saludo
 
 
  --
  To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
  with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
  Archive:
 https://lists.debian.org/camf5f5c_op9a8158xvdqebambdekqfirrc43dgc14f2os0t...@mail.gmail.com
 
 
  Muchas gracias.
 
  Voy a realizar pruebas y comento.
 
  Saludos.

 Lo único que los permisos que hay en /etc/adduser.conf son para la
 creación de directorios, pero no sé como se comportará para la
 creación de ficheros...

 Saludos.


 --
 To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/caj2aoa8jyucjw6km6yohwuql33-gabjo9ogugokvn6beq_i...@mail.gmail.com


O pudes usar ACL[0].

Instalas acl, configuras en /etc/fstab el sistema de ficheros en el que
está montado /var/www y ejecutas como usuario

setfacl -R -m u:www-data:rwx -m u:`whoami`:rwx /var/www
setfacl -dR -m u:www-data:rwx -m u:`whoami`:rwx /var/www

Supongo que el usuario tiene permisos de escritura en /var/www


Saludos,

[0]
http://wiki.salud.gob.sv/wiki/Desarrollo_web_Symfony2#Permisos_a_las_carpetas_cache_y_logs

-- 
Roger Orellana


Re: OT: Muy OT: Clamav -Immunet

2014-04-30 Por tema Fabián Bonetti
On Wed, 30 Apr 2014 09:45:14 -0400
Roberto Quiñones robe...@acshell.net wrote:

 
 Existe un antivirus [1] al igual que ClamWin, utiliza el motor de
 ClamAV y lo mejor a ClamWin es que si viene con protección en tiempo
 real, cosa que hoy en día se necesita mucho en equipos de escritorio
 basados en Windows.
 
 [1] http://www.moonsecure.com/
 
 Saludos
 -- 

Parece inestable ese moonsecure.

Intente actualizar la bd de virus y me tiro este error.

The system is some how stopped, this normally should not 
happen.
Either it was abnomarlly crashed or user manually stop it.

No status could be retrieved nor scanning activirus could 
be done.

Parece abandonado ese proyecto.



-- 
Servicios:. http://mamalibre.com.ar/plus
MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina


pgpgImvSE7f86.pgp
Description: PGP signature


Re: [OT] Re: Problemas Nat Asterisk en Debian atravesando 2 firewall

2014-04-30 Por tema Yacton Richol


Maykel Franco maykeldeb...@gmail.com wrote:

El día 24 de abril de 2014, 15:44, Camaleón noela...@gmail.com escribió:
 El Thu, 24 Apr 2014 10:17:51 +0200, Maykel Franco escribió:

 Hola buenas, tengo un servidor asterisk bajo debian. En la misma red
 funciona perfecto e incluso en otra red que pasa por el mismo firewall
 también funciona.

 El problema viene cuando se realizan llamadas atravesando 2 firewall(2
 nat), que no se escucha la voz...Según he estado mirando en internet
 puede deberse a que necesite utilizar stun.

 Uso puertos por defecto 5060 para registro de los clientes y 1:2
 para streaming de voz.

 Alguien ha tenido problemas con asterisk en debian atravesando por
 varios firewall?

 Que la santa espiral te asista, amigo :-)

 Vas a tener que hilar fino, fino para ajustar los cortafuegos con el voip,
 yo me las veo y me las deseo con los terminales Cisco SPA5xx (hay varios
 terminales con varias extensiones registradas...) y eso que sólo hay un
 cortafuegos y un NAT de por medio.

 Al final tuve que llegar a un consenso: unos terminales usan servidores
 STUN y otros están configurados para hacer NAT traversal con reenvío de
 puerto.

 Saludos,

 --
 Camaleón


 --
 To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/pan.2014.04.24.13.44...@gmail.com


Gracias por contestar Camaleón.
Y otra cosa, el servidor stun tiene que estar en el mismo firewall
donde tienes nateado el puerto 5060 de registro y el de streaming
1:2? O el servidor stun puede estar en otro firewall que no
sea ese?
Imaginaros que el firewall por donde pasa el tráfico de asterisk no
tenga para montar un servidor stun...
Saludos y gracias como siempre.

a mi paso así pero cuando usaba SIP yo cambien al IAX2 y se acabo el problema 
... 

-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJ2aOA9qLC4MZc=+drifz34cf12t5crpmut-834-ggo...@mail.gmail.com


Evitar borrado de archivos dentro de un directorio.

2014-04-30 Por tema Emmanuel Brenes

Buenas, buenas, listeros.
Tengo una duda a raíz de una experiencia algo amarga, rápidamente, perdí 
todo hace dos días porque puse el comando remove con un parámetro 
recursivo y forzado, así que ~ al cielo de los bits...
Buscando un rato encuentro que se pueden usar alias para evitar 
desastres similares o incluso chattr con parámetros de inmutable, pero 
noto que si se hace recursivo -por lógica- en un directorio, por ejemplo 
/Importantes este y sus subdirectorios y archivos, serían inmutables, 
siendo el problema agregar un archivo, ya que habría que des-inmutar todo.
¿Conocen algún método que prevenga la metida de patas? Actualmente uso 
un alias para del que será el que use de ahora en adelante, pero rm 
a veces se vuelve necesario con archivos molestos...

Saludos y gracias.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu0-smtp17669a1e028811494a79eeea1...@phx.gbl



Re: Editar el archivo /etc/fstab (era: (unknown))

2014-04-30 Por tema Haylem Candelario Bauzá del INOR
y si quitas vfat y pones fat32, seguro que la particion es fat?
y no ntfs?

te recomiendo que pruebes montandolo con mount -t vfat .
y ve cambiando el formato hasta que funciones y luego pasas al /etc/fstab

-- 
Si dominas los Bits, dominas el mundo


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201404301808.56526.hay...@inor.sld.cu



Re: Evitar borrado de archivos dentro de un directorio.

2014-04-30 Por tema Santiago Vila
On Wed, Apr 30, 2014 at 03:52:13PM -0600, Emmanuel Brenes wrote:
 ¿Conocen algún método que prevenga la metida de patas?

En el .bashrc de root encontrarás esto comentado:

alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

Pero lo que te recomiendo de verdad es que hagas copias de seguridad
diarias. Si es posible, de forma automática.


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140430223643.ga12...@cantor.unex.es



Re: Evitar borrado de archivos dentro de un directorio.

2014-04-30 Por tema Emmanuel Brenes

El 30/04/2014 16:36, Santiago Vila escribió:

On Wed, Apr 30, 2014 at 03:52:13PM -0600, Emmanuel Brenes wrote:

¿Conocen algún método que prevenga la metida de patas?


En el .bashrc de root encontrarás esto comentado:

alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

Pero lo que te recomiendo de verdad es que hagas copias de seguridad
diarias. Si es posible, de forma automática.




Siento que es muy útil -hasta ahora lo veo, jeje- pero ¿qué pasa con los 
parámetros que se envían al comando? Por ejemplo el -rf, eso aunque 
ayude debido al error que da, podría complicar las cosas en casos de 
borrado recursivo (directorios)... es complejo lo sé. Por ahora tengo en 
alias a 'del' para mover -a la basura- y no borrar y rm tendré que 
aprender a usarlo con '-ri' para evitar metidas de pata.


Con respecto a los respaldos, lo sé, fue una torpeza gigante de mi 
parte, pero al menos lo más valioso sí lo tenía en una llave USB, no 
obstante, es el único medio y es corto (16 GB). ¿Existe forma de usar 
Sync y comprimir el resultado? Porque si es así, lo haría así y sería 
bastante útil.


Saludos y gracias.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu0-smtp12745211f13c0a21933d913a1...@phx.gbl



Re: Evitar borrado de archivos dentro de un directorio.

2014-04-30 Por tema Flako
El día 30 de abril de 2014, 18:52, Emmanuel Brenes
brenil...@hotmail.com escribió:
 ¿Conocen algún método que prevenga la metida de patas?
Si... intentar no ser tan distraído...
Creo que todos alguna vez  hemos borrado cosas importantes (en todos
los SSOO que hemos tenido acceso...), y a veces no importa que muestre
un cartel de advertencia... muchas veces ni lo leemos y le damos al
[Si/Aceptar]


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadqxbrswaenocg1xrod08e5vxffd4phpjsnbpbj2g3nugbz...@mail.gmail.com



Re: Evitar borrado de archivos dentro de un directorio.

2014-04-30 Por tema Emmanuel Brenes

El 30/04/2014 17:08, Flako escribió:

El día 30 de abril de 2014, 18:52, Emmanuel Brenes
brenil...@hotmail.com escribió:

¿Conocen algún método que prevenga la metida de patas?

Si... intentar no ser tan distraído...
Creo que todos alguna vez  hemos borrado cosas importantes (en todos
los SSOO que hemos tenido acceso...), y a veces no importa que muestre
un cartel de advertencia... muchas veces ni lo leemos y le damos al
[Si/Aceptar]




Ciertamente, compañero, por estar apresurado no fui escrupuloso y 
bueno... 200 GBs menos, al menos míos y no de una empresa/trabajo.
Ahora que, una advertencia nunca cae mal, a como cambiar la costumbre 
del usar '-f' y evitar esos tragos.


Saludos.


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/blu0-smtp18142d0998ba9ab3795c049a1...@phx.gbl