Mensajes

En la pagina de udisks esta esto:

Código (text) [Seleccionar] Expandir


<action id="org.freedesktop.udisks2.filesystem-fstab">
   <_description>Mount/unmount filesystems defined in the fstab file with the x-udisks-auth option</_description>
   <_message>Authentication is required to mount/unmount the filesystem</_message>
   <defaults>
     <allow_any>auth_admin</allow_any>
     <allow_inactive>auth_admin</allow_inactive>
     <allow_active>auth_admin_keep</allow_active>
   </defaults>
 </action>

http://udisks.freedesktop.org/docs/latest/udisks-polkit-actions.html

Edit: No creo que sea cosa de auth_admin_keep. Parece que simplemente extiende un periodo de gracia para la autentificacion, como sudo. Viendo el wiki de arch sobre polkit parece que hay politicas por grupo o mas bien que tienen preferencia sobre los defaults. Hay reglas debajo de /etc/polkit-1/rules.d y /usr/share/polkit-1/rules.d al menos en mi arch.

En arch parece ser que el grupo es storage:

Código [Seleccionar] Expandir


/etc/polkit-1/rules.d/50-udisks.rules

polkit.addRule(function(action, subject) {
  var YES = polkit.Result.YES;
  var permission = {
    // only required for udisks1:
    "org.freedesktop.udisks.filesystem-mount": YES,
    "org.freedesktop.udisks.filesystem-mount-system-internal": YES,
    "org.freedesktop.udisks.luks-unlock": YES,
    "org.freedesktop.udisks.drive-eject": YES,
    "org.freedesktop.udisks.drive-detach": YES,
    // only required for udisks2:
    "org.freedesktop.udisks2.filesystem-mount": YES,
    "org.freedesktop.udisks2.filesystem-mount-system": YES,
    "org.freedesktop.udisks2.encrypted-unlock": YES,
    "org.freedesktop.udisks2.eject-media": YES,
    "org.freedesktop.udisks2.power-off-drive": YES,
    // required for udisks2 if using udiskie from another seat (e.g. systemd):
    "org.freedesktop.udisks2.filesystem-mount-other-seat": YES,
    "org.freedesktop.udisks2.encrypted-unlock-other-seat": YES,
    "org.freedesktop.udisks2.eject-media-other-seat": YES,
    "org.freedesktop.udisks2.power-off-drive-other-seat": YES
  };
  if (subject.isInGroup("storage")) {
    return permission[action.id];
  }
});

voy a probar con lo del rc.local, creo que antes tambien lo tenia asi.

donde me conviene montar en /mnt/... o /media/... o es indiferente?

Es una convencion, Media es generalmente usado para montar elementos de dispositivos removibles. CD, USB, floppy, etc. Honestamente, puedes montarlo en cualquier otro lugar.

Como te dice Slava_TZD, tienes la opcion de noauto por lo que no lo monta al bootear. El problema con montar elementos de la red es que el sistema tiene que esperarse a que los servicios de red se levanten y que la conexion este activa. Puede alentar tu proceso de booteo.

Encima de la opcion de usar rc.local si usas systemd tambien puedes montar el dispositivo hasta que alguien intente acceder al dispositivo. Necesitas usar la opcion:

Código [Seleccionar] Expandir


x-systemd.automount

Junto con la opcion noauto, para que no monte al bootear.

[Bash (Bourne Again Shell)]

TL;DR: Usa las etiquetas correspondientes

Últimamente he visto bastantes mensajes sin formato alguno. Usuarios nuevos generalmente. Así que he decidido explicar el problema y la solución.

Primero, el problema. No hay una clara distinción entre texto y código/errores/logs/etc. Al estar leyendo, lo siguiente puede ser parte de un programa, luego regresar a una conversación, luego volver a escribir parte de un programa, etc. Al final obtenemos un mensaje el cual es muy difícil de leer. Observemos un caso:

Usuario solicita ayuda con un shell script pero simplemente pega el código encima del mensaje. La transición no es tan difícil en este caso, sin embargo los miembros pertenecientes al código no son muy claros.

La lectura es algo pesada sobre todo con strings y es un tanto difícil de corregir. Ahora, si usamos etiquetas GESHI:

Obtenemos un mensaje mas fácil de leer. Algunos errores se pueden observar mejor de esta forma:

Es importante observar que lo único que cambio en el mensaje es que ha agregado etiquetas code delimitadas por [] al principio y al final del texto seleccionado. Noten que en la primera etiqueta se usa tambien '=bash'. Esto significa que el codigo sigue las reglas sintacticas del lenguaje bash.

Esta no es la única forma, también es posible de hacerlo asi:

Es importante posicionar el texto del código/log/etc en medio de las dos etiquetas para que reciban el formato adecuado.

Algunos se habran dado cuenta que el script tecnicamente no especifica la shell de Bash (Bourne Again Shell) sino de sh de las cuales hay muchas posibilidades.. (Bourne Shells, DASH, etc). Realmente puede acabar siendo utilizado en shells diferentes pero por lo general siguen las mismas reglas sintácticas por lo que es posible usarlo para los dos tipos. Es importante tratar de usar el modo correspondiente al lenguaje a utilizar sin embargo no siempre es posible, no se encuentran disponibles todos los lenguajes de modo que queda a su discreción utilizar un modo similar o no.

En caso de no encontrar un lenguaje o si quieren evitar posibles confusiones con uno que es similar, pueden usar simplemente las etiquetas code sin ningún parámetro.

Tal es el caso con la gran mayoría de los logs y mensajes de errores que quieran publicar. El resultado es un poco mas legible y se encuentra espaciado uniformemente (la longitud de los caracteres es la misma).

Al usar las etiquetas correspondientes, la lectura y comprensión de sus mensajes es más fácil. Sus aportaciones son mas entendibles y la probabilidad de que alguien aporte a su tema aumenta.

He instalado  Oracle_VM_VirtualBox_Extension_Pack-4.3.4-91027.vbox-extpack la version del VBOX que tengo es 4.3.20
Con este paquete he seleccionando controlador USB 2.0 la makina arranca y al poco aborta, si no lo selecciono la makina arranca normal.
Hay muchas versiones de paquetes para instalar , no se si es cuestión de ir probando cual es mi versión, o el problema es otro.  

Prueba con este?

http://dlc-cdn.sun.com/virtualbox/4.3.20/Oracle_VM_VirtualBox_Extension_Pack-4.3.20-96996.vbox-extpack

Lo se, simplemente dije esto porque seguro que tiene una politica en ACCEPT, desde mi punto de vista y desde el de mucha gente, es mucho mejor tener una politica en DROP, para lo que el quiere hacer.

No colocar un DROP a 1.2.3.4 y luego crear otra con un ACCEPT y el puerto.

Solo dije una recomendacion ya se que el problema no va de eso, la proxima no digo nada.

Un saludo.

No digo que una política DROP no sea mejor, es la manera en la que planteaste la solución. Si puedes usar una política DROP, pero tienes que agregar reglas ACCEPT para tus puertos.

Si usas una politica DROP:

Código (bash) [Seleccionar] Expandir


iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 1.2.3.4 -j ACCEPT
iptables -A INPUT -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW --dport 80 -j ACCEPT

Pero las reglas para banear las vas a tener que insertar a partir del indice 3.

Código (bash) [Seleccionar] Expandir


sudo iptables -I INPUT 3 -s x.x.x.x -j DROP

Si pones tus reglas al principio de la tabla puedes perder la conexion porque el DROP pasa antes que el ACCEPT. Si pones tus reglas al final de la tabla el ACCEPT del puerto 80 hace ACCEPT antes que llegue a los drops del puerto 80. Es decir la gente que baneaste puede seguir accediendo al sistema atraves de los puertos que habilitaste.

Si usas una poltica ACCEPT:

Código (bash) [Seleccionar] Expandir


iptables -P ACCEPT
iptables -A INPUT -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 1.2.3.4 -j ACCEPT

Para banear gente, simplemente agregas al final de la tabla tu regla:

Código (bash) [Seleccionar] Expandir


sudo iptables -A INPUT -p tcp -s x.x.x.x -j DROP

En ambos casos:

1.2.3.4 viene siendo tu ip.
x.x.x.x viene siendo la ip que quieres banear.

La diferencia entre las dos politicas, es que usando una politica DROP es mas restrictiva.

Genial!, creo que tengo un pato de goma de mi hijo en el baño xD pero si comienzo a usarlo entonces me voy a ahorrar mas de la mitad de los post en el foro y la gente que pueda tener los mismos problemas no va a encontrar una respuesta

Me sale mas fácil hacer un barco de papel, lo pondré al lado de mi monitor.

Al final el baneo lo hice baneando la ip por completo y luego habilitandole el acceso al puerto 22 y finalmente guardando las reglas y al final una tarea programada para eliminar las reglas.

Código (php) [Seleccionar] Expandir

<?php
system(
'sudo iptables -I INPUT -s '.escapeshellarg($_SERVER['HTTP_WIM_REAL_IP']).' -j DROP && '.
'sudo iptables -I INPUT -p tcp -s '.escapeshellarg($_SERVER['HTTP_WIM_REAL_IP']).' --dport 22 -j ACCEPT && '.
'sudo service iptables save && '.
'echo "sudo iptables -D INPUT -s '.escapeshellarg($_SERVER['HTTP_WIM_REAL_IP']).' -j DROP ; sudo iptables -D INPUT -p tcp -s '.escapeshellarg($_SERVER['HTTP_WIM_REAL_IP']).' --dport 22 -j ACCEPT ; sudo service iptables save;" | sudo at now + '.(int)$unban_minutes.' minutes'
);

Yo pense que querias agregar solo una regla para que no te banee a ti. En lugar de agregar la regla que permite acceso al SSH por cada IP, mejor simplemente agrega una regla para permitir acceso SSH al principio de la tabla:

Código (bash) [Seleccionar] Expandir


iptables -I INPUT -p tcp --dport 22 -j ACCEPT

Igual si los baneas, les estas permitiendo acceso SSH asi que es mejor dejar el acceso abierto a SSH en lugar de agregar una regla nueva por cada IP.

No es mejor, establecer una politica DROP en INPUT y luego dejar paso a las direcciones y puertos convenientes?

Código (bash) [Seleccionar] Expandir

iptables -F
iptables -X
iptables -P INPUT DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 --syn -m state --state NEW -j ACCEPT

Un saludo.

El objetivo parece ser denegar a algunos, no permitir a algunos.

Parece que thunar-volman usa udisks que usa polkit. Estoy leyendo la pagina de udisks y en el segundo parrafo veo esto:

ACCESS CONTROL
       By default, logged-in users in active log-in sessions are permitted to perform operations (for example, mounting, unlocking or
       modifying) on devices attached to the seat their session is on. Access-control is fine-grained and based on polkit(8), see the
       "Authorization Checks" chapter in the udisks documentation for more information. Note that the x-udisks-auth option can be used in the
       /etc/fstab and /etc/crypttab files to specify that additional authorization is required to mount resp. unlock the device (typically
       requiring the user to authenticate as an administrator).

Parece ser que la opcion x-udisks-auth es lo que estas buscando.

Cuando dices IP Pública e IP Privada me imagino que la red solo es accesible a través de NAT. No puedes enviar ICMP Echo Request a un host en especifico a menos que configures el Router que esta haciendo NAT para que envie todo el trafico ICMP al equipo en cuestion detras de la NAT, de no ser asi el comportamiento mas usual es que el Router reciba el ICMP Echo Request y haga el ICMP Echo Reply. Sin embargo es posible enviar ICMP Echo Request desde un equipo detrás de una NAT a un equipo que no este detrás de una NAT.

Hay un RFC que justamente describe como es esto posible:

https://tools.ietf.org/html/rfc5508

Tus DNS parecen estar comprometidos. La ip de multianuncios es:

89.202.162.58

No estan haciendo uso de RR tampoco.

Código [Seleccionar] Expandir

http://76.74.255.149/

Esa es la pagina que estas viendo.