Mostrando entradas con la etiqueta acceso remoto. Mostrar todas las entradas
Mostrando entradas con la etiqueta acceso remoto. Mostrar todas las entradas

[HowTo] Reproducir contenido DLNA desde Kodi

Posted: sábado, 8 de febrero de 2020 by Termita in Etiquetas: , , , , , , , , , , , , ,
0

En Kodi el servicio DLNA recibe el nombre de UPnP.

Para poder reproducir en Kodi contenido remoto de un servidor DLNA hay que hacer lo siguiente:

1. Activar UPNP
configuración (icono del engranaje) → servicios → UPnP/DLNA → Enable UPnP support

2. Agregar fuente (el servidor DLNA)
configuración (icono del engranaje) → File Manager → Añadir Fuente → Browse → UPnP devices → seleccionar el servidor


A partir de este momento, cuando entremos en la 'Sección Archivos' de los apartados 'video', 'música' y similares tendremos disponible el servidor DLNA para explorar su contenido.

[HowTo] Transmission controlado remotamente en RaspBerryPi

Posted: domingo, 30 de junio de 2019 by Termita in Etiquetas: , , , , , , , ,
0

sudo apt update
sudo apt upgrade
sudo rpi-update

sudo apt install transmission-daemon

sudo /etc/init.d/transmission-daemon stop

sudo usermod -aG debian-transmission miusuario

mkdir /carpetadecompletados
mkdir /carpetadeincompletos

sudo cp /etc/transmission-daemon/settings.json /etc/transmission-daemon/settings.json.backup
sudo nano /etc/transmission-daemon/settings.json
"download-dir":"/carpetadecompletados"
"incomplete-dir":"/carpetadeincompletos
"
"incomplete-dir-enabled":true
"rpc-authentication-required":true
"rpc-bind-address":"0.0.0.0"
"rpc-whitelist-enabled":false
"rpc-enabled":true
"rpc-username": "TUUSUARIO",
"rpc-password":"TUPASSWORD"

(*) La contraseña, aunque podamos pensar que al guardar el archivo de configuración se mostrará en texto plano, creo que no se mostrará.
De alguna forma, al guardar el fichero de configuración, la contraseña se mostrará encriptada. Desconozco el algoritmo y el grado de seguridad de éste, mas la contraseña no se verá en texto plano.
En principio, el usuario por defecto -a no ser que lo cambiemos- es transmission


sudo chown -R debian-transmission:debian-transmission /carpetadecompletados
sudo find /carpetadecompletados -type d -print -exec chmod 775 {} \;
sudo find /carpetadecompletados -type f -print -exec chmod 664 {} \;

sudo chown -R debian-transmission:debian-transmission /carpetadeincompletos
sudo find /carpetadeincompletos -type d -print -exec chmod 775 {} \;
sudo find /carpetadeincompletos -type f -print -exec chmod 664 {} \;

sudo /etc/init.d/transmission-daemon start


Controlaremos remotamente Transmission desde el navegador, introduciendo: http://ipdelordenadorconTransmission:9091

Podemos agregar descargas, cancelarlas, etcétera.




-------------------------------------------------

Fuentes:



[HowTo] nohup: para que un trabajo iniciado en segundo plano no se cancele "si nos vamos"

Posted: martes, 25 de junio de 2019 by Termita in Etiquetas: , , , , , , , ,
0

¿Cómo hacer que si iniciamos un trabajo en segundo plano -remotamente o no- y "nos vamos" (hacemos un exit y cerramos la sesión del usuario con el que lo hemos iniciado, cerramos el terminal, estando en remoto apagamos el ordenador cliente, es decir el ordenador desde el que hemos ejecutado el comando, etcétera..) NO se cancele el trabajo?

Con nohup, tal como he leído que hace Atareao.

(*) Que conste que esto sólo lo he probado con scripts y comandos que NO abren la "pantalla" de un programa como, por ejemplo, hace Midnight Commander. Desconozco si sería viable hacerlo con ese tipo de comandos / aplicaciones.

A parte de nohup existen otras formas, otros comandos, que, como nohup, permiten controlar que el trabajo que iniciamos no se cancele si "nos vamos".
Los enumeraré ahora. Mas los trataré en otra entrada de este blog[], pues -entre otras cosas- aún nos los probé:
tmux [http://www.sromero.org/wiki/linux/aplicaciones/tmux]
screen [https://www.ochobitshacenunbyte.com/2019/04/24/que-es-y-como-funciona-el-comando-screen-en-linux/]
byobu [https://medium.com/@aliartiza75/what-is-byobu-and-how-to-use-it-b09722008d65]


Al grano mas primero hay que definir el concepto "SEGUNDO PLANO". Échenle un vistazo a ESTA[@] entrada del blog y también a:
https://www.atareao.es/como/procesos-en-segundo-plano-en-linux/
https://blog.carreralinux.com.ar/2016/09/procesos-en-segundo-plano-linux/


Ilustraremos el uso de nohup de la siguiente forma:

Estamos en remoto, conectados a otra máquina por ssh, y queremos calcular la suma de verificación de un archivo grande.
Como estamos muy atareados, no podemos permitirnos estar parados mirando cómo el trabajo se lleva a cabo y necesitamos apagar nuestro ordenador -que es el cliente desde el que lanzamos comandos en el ordenador remoto- para hacer otras cosas. Tampoco podemos permitirnos que haciendo esto el trabajo que iniciamos se cancele.

Por eso ejecutaremos el trabajo NO de esta forma:
sha256sum nombredearchivogrande > nombredearchivogrande.sha256.txt

SINO de esta otra forma:
nohup sha256sum nombredearchivogrande > nombredearchivogrande.sha256.txt &

Así, si "nos vamos" (apagamos nuestra máquina cliente, por ejemplo) el trabajo continuará en la máquina remota (servidor).

Esta imagen muestra lo que hemos hecho:


Leyenda:

1. Lanzo el comando
nohup comando &

2. El sistema responde informando que le ha asignado el número "1" a ese proceso en "segundo plano" (a causa de añadir "&" al final) que hemos iniciado.

3. [comprobación] La orden jobs nos muestra:
4. la lista de procesos que tenemos iniciados en segundo plano, el número que se le ha asignado a cada uno y el estado en que están. En nuestro caso el proceso que hemos lanzado es el nº 1 y está "Ejecutándose".

5. [comprobación] fg 1
Trae a primer plano el proceso nº 1, que no es otro que el que lanzamos en el punto 1.

6. Ctrl + Z
Pausa el proceso

7. bg 1
Manda al proceso nº 1 a sels -lagundo plano y lo reanuda.

8. [comprobación] jobs
9. vemos que el proceso nº 1 está efectivamente ejecutándose.


10. [nos vamos] salimos del usuario con el que, con sudo, estábamos trabajando.
Acto seguido cerramos la conexión ssh que teníamos con el servidor remoto donde aún se está ejecutando el comando que lanzamos hace apenas unos instantes.


11. Pasado un rato nos volvemos a loguear en el servidor remoto donde dejamos ejecutándose el proceso nº 1 aquel... ¿se acuerdan?

12. [comprobación] ls -la
Listamos el contenido de la carpeta.
13. [comprobación] Vemos que el archivo resultante del comando se ha creado y que su tamaño es mayor que cero. Esto es indicio de que el trabajo concluyó correctamente a pesar de haber cerrado la conexión.

14. [comprobación] cat nombredelarchivoresultantedeltrabajo.txt
Constatamos que el contenido es correcto y que el trabajo concluyó correctamente a pesar de haber cerrado la conexión.




---------------------------------------------

Fuentes:







Kodi y su acceso remoto: agujero a controlar

Posted: sábado, 13 de abril de 2019 by Termita in Etiquetas: , , , , , ,
0

Dicen que si la interfaz de acceso remoto de Kodi está mal protegida es posible que un tercero pueda ver sus complementos y otros tipos de información confidencial, incluídos los videos personales y privados, y también cambiar la configuración de los usuarios.
La interfaz de acceso remoto de Kodi permite que se pueda gestionar remotamente a través de un entorno web. Si la interfaz remota no está protegida por contraseña, cualquiera puede acceder con tan solo conocer la ip.

--------------------------
Fuente:
https://www.redeszone.net/2018/01/02/kodi-podria-estar-espiandote-sin-lo-sepas/?utm_source=related_posts&utm_medium=manual

[HowTo] Configurar el acceso SSH a Raspberry Pi directamente en la microSD

Posted: lunes, 25 de febrero de 2019 by Termita in Etiquetas: , , , , ,
0

Creo archivo llamado 'ssh' en la partición boot del microSD:
     touch ssh

Cuando instertemos la microSD en Raspberry Pi, tendremos habilitado el acceso SSH.
Pero éste será cableado, es decir, por rj45.
Si queremos acceder de forma inalámbrica, se puede configurar la conexión wifi también antes de conectar la tarjeta microSD a Raspberry Pi.




más información

0

Por alguna razón acceder vía VNC a la versión 2018-11-13 se resiste más de lo debido. Desconozco exactamente las causas que hacen que cuando, por ejemplo, tratamos de conectar mediante el cliente Remmina desde Ubuntu 18.04 obtengamos este rechazo:
    "esquema de autentificación desconocido del servidor vnc"
 

Estos son los detalles del servidor VNC que trae de serie Raspbian 2018-11-13. Hace referencia a VNC Server, Real VNC, VNC Viewer. El puerto que utiliza juraría es el 5900.




SOLUCIÓN

1. En el servidor VNC de Raspbian2018-11-13


Modificamos método de Autentificación para que sea mediante "contraseña de VNC"

Agregamos un usuario de tipo "administrador" y le asignamos una contraseña


2. En el cliente VNC, en mi caso Remmina (en Ubuntu 18.04)


En el cliente Remmina creamos una conexión y la configuramos: le asignamos un nombre identificativo, establecemos el protocolo (VNC), especificamos la IP del servidor VNC y también el usuario y contraseña que agregamos en el paso anterior (en el servidor VNC de Raspbian).



más información:

VNC vs. RDP

Posted: by Termita in Etiquetas: , , ,
0

RDP

    RDP stands for Remote Desktop Protocol. It is a proprietary protocol built by Microsoft to let users to graphically control remote computer.
    RDP logs in a remote user to the server computer by effectively creating a real desktop session on the server computer including a user profile.
    RDP works in the same way as if the user had logged in to the physical server directly.
    RDP can support multiple remote users logged in to the same server that completely unaware of each other.



VNC

    VNC stands for Virtual Network Computing. It is an open platform independent graphical desktop sharing system designed to remotely control another computer.
    VNC follows the older model of simply showing whatever is on the screen with no forced logins required.
    VNC connects a remote user to the computer itself by sharing its screen, keyboard and mouse.
    Consequently, when several users (including the one operating the real physical monitor and keyboard) connect to the same server they see the same thing and they type on the same keyboard.
    VNC has security implications; if you remote into a machine that an Administrator is logged into, you'll effectively be an Administrator. And if you're both trying to use the computer at the same time, it's even more fun!



Similarities between both

    Both RDP and VNC technologies require client side and server side software to support communication protocol.
    Both technologies use direct peer-to-peer communication. It means that the local user computer directly connects to the remote computer
    Both can't handle multiple monitors in any way; you'll only see the primary monitor (but there are ways to see all monitors using other tools)





más información: