I've read a bit about IPFS and even added a feature to my comic book reader [1], but I am having trouble getting the basic flow to work:
I created a VM running on Google Cloud that has go-ipfs installed
ipfs daemon is running
on the VM, I added a file (which I believe pins it): hash Qma8Ru1qrJjeVcw5NpY8nXrCWnRhwZpKx617vV3atTYA9t
I can see lots of peers connecting via "ipfs swarm peers"
on my local computer, I installed go-ipfs
When I try on my local computer:
$ ipfs get Qma8Ru1qrJjeVcw5NpY8nXrCWnRhwZpKx617vV3atTYA9t
it just sits there...
Is there a good way to monitor what's going on here (like is the IPFS node in the VM set up correctly)?
Am I doing something wrong?
[1] https://github.com/codedread/kthoom
For the readers, the answer was that it was needed for the peer behind the NAT to dial to the peer in the public IP.
For folks wanting to learn more about how to deal with this automatically, check our tutorials on:
Circuit Relay https://github.com/ipfs/js-ipfs/tree/master/examples/circuit-relaying
Using multiple transports (including WebRTC that supports NAT Holepunching) https://github.com/libp2p/js-libp2p/tree/master/examples/transports
Related
is there a way to connect a dvr tuner to a Plex Server hosted in Hyper-V?
I have searched but could not find a Question about this topic.
My build is a Win22 Datacenter Server running Plex in Hyper-V. A Hauppauge dualHD is connected to the Win22 Datacenter Server via USB.
Thanks for your help!
Current Answer
I'm updating my answer as I didn't realize it was a tuner and not a DVR box connected to your TV.
From what I'm seeing online, your best bets are:
use Enhanced Session Mode to connect the device over RDP (which only supports some devices)
use a third-party tool such as Donglify (this is from results on Google. Buy at your own digression) to allow USB passthrough
use a Type 2 hypervisor (VirtualBox, VMware) to run your instance of Plex instead
run Plex outside of Hyper-V on the same system with a sandboxed user
run Plex on another device entirely, such as a Raspberry Pi.
I can't help with the first, as it requires some gpedit.msc magic I cannot do, or second as I have never used one.
3rd option will reduce program speeds which may cause slowdown if multiple people stream at once.
4th option is my personal recommendation, as you bypass the need to use a hypervisor entirely and keep on the same device.
5th is only good if you use a USB-based drive and have a decent bit of experience with Linux.
Old Answer
Kept for the sake of archival.
You'll want to use Powershell and the Add-NetNatStaticMapping cmdlet to allow inbound connections to the Hyper-V server. This will need a vNAT adapter set up. See the linked blog post (not mine) if you need help with that, too.
Assuming the vEthernet connection has an internal IP of 192.168.10.2 and a NAT network name of NATSwitch, with Plex on the default port of 32400:
Add-NetNatStaticMapping -ExternalIPAddress "0.0.0.0/24" -ExternalPort 32400 -Protocol TCP -InternalIPAddress "192.168.10.2" -InternalPort 32400 -NatName NATNetwork
You will most likely need to replace the internal IP, port, and NAT name.
After this is set up, you'll need to point your DVR to the IP of the Windows Server box.
Sites referenced:
Plex support page on ports to forward
A GitHub user's blog, specifically a post on port forwarding
I'm looking to use WebRTC in a project where I need to livestream video from one computer, a robot with a wifi hotspot and USB camera, over a local network to another computer, a controller for the robot. Both computers in this case are single board computers and the video stream is one-way. I'd also like the two computers to communicate data to each other in both directions. I found WebRTC in my research and it seems to have both of these functionalities that I'm looking for.
From initial testing with the demo NodeJS programs, WebRTC seems to be almost exactly what I'm looking for. One big bump I've been trying to get over though is that it seems to require by default an online signaling server to be used between the two clients. I researched and found that it's possible to create the signaling server within the local network with a third computer, but such a setup isn't appropriate for my project.
I've looked into other solutions and came across OpenVidu which implements WebRTC but allows the signaling server to be built into one of the client computers (at least that's what I've read in another stack overflow post). I have yet to test this tool to see if it resolves my issue, but I'm blocked currently by the docker image used by the project not supporting ARM processors, which are employed by my single board computers, and thus requiring special installation.
Before I go through that process which may or may not work, I wanted to ask if there's another simpler solution to running WebRTC without internet access and without needing a third computer as a signaling server or if there were any suggestions for tools other than WebRTC that would be better for my application. I'm very new to the technology and could definitely be missing an easy or existing solution. Any help on this matter would be greatly appreciated.
For those curious, the single board computers being used are NVidia Jetson Nanos.
Found the solution. Using the Google Codelabs example, the fix involved just removing the default ice server in the config. Essentially, it meant changing
const config = {
iceServers: [
{urls: ["stun:stun.l.google.com:19302"]}
]
}
to
const config = {
iceServers: []
}
you can run local turnserver on your lan. It is very easy and straight forward.
check this enter link description here
after install just run
turnserver -p 19302
Now your config file:
const config = {
iceServers: [
{urls: ["stun:<<YOUR HOST IP>>:19302"]}
]
}
I have what I believe to be a very simple question.
Context
I have a Raspberry Pi Zero W running Raspbian Lite (2020-02-13-raspbian-buster-lite.img).
Question
How do I change just one file on the SD Card, e.g. in the host partition, to auto-configure the raspberrypi as a wifi hostpot, and call it raspberrypi.
Also, I would like to be able to set the hotspot to be open, or with a password raspberry (just like the ssh password :) ).
What I tried already
I found lots of instructions on installing software packages, but unless I'm connecting via ssh already, then I can't run commands unless I'm already networked to the pi.
Why do I want this?
I want to be able to do this, for much greater ease of connecting to a raspberrypi in the first instance, for example, along with enabling ssh, this would allow very simple ease of access for incoming connections.
Only an idea
Finally, what does anyone think of the idea of enabling this by default in Raspbian. It can be disabled is required, but would substantially ease the process of connecting to a Pi with a Raspbian image out of the box - allowing a use to see so-called "proof-of-pi" immediately after first boot.
As far as I've seen, configuring the Pi before-first-boot by editing the boot partition files is limited. However there are some custom tools out there where you can look at creating a custom image or design some provisioning steps for your Pi.
PiBakery is a tool for creating custom images of Raspbian. Setting up a WiFi hotspot will most certainly require a custom script for tool installation and configuration.
I know that you can configure a SD card to auto-connect to WiFi (for normal network connections) by creating a wpa_supplicant.conf file and setting some values in boot's config.txt, you may want to check some of the documentation from the Raspbian project regarding config.txt. Keep in mind that the default raspberrypi.org image is slightly different than the Raspbian Project's image, so your mileage may vary.
Finally, depending on your use case for this/deployment strategy, you can also look into changing the Pi's boot mode so that it boots from a network host, kind of like "PXE Boot" for Windows machines. You'd have to host a provisioning server that the Pi can get information from and sync up with, which may be out of the bounds of what you're trying to accomplish, but I figured I'd bring it up!
Is there a difference between using salt-proxy ssh and directly salt-ssh? I'm interested because according to documentation both aimed to run remote commands without agent installation on the end machine.
You cant simply do salt-ssh on a proxy minion, for which you would have to write your own custom ssh interface to the remote system, because your proxy minion may not support doing salt-ssh.
How to choose between using salt-ssh vs salt-proxy totally depends on the type of a minion system.
As stated in the saltstack documentation - https://docs.saltstack.com/en/latest/topics/ssh/index.html and
https://docs.saltstack.com/en/latest/topics/proxyminion/index.html
For salt-ssh to be used, the remote system must have python installed - one of the criteria. For example, controlling ubuntu from centos.
As stated in the salt-proxy doc,
Proxy minions are a developing Salt feature that enables controlling
devices that, for whatever reason, cannot run a standard salt-minion.
Examples include network gear that has an API but runs a proprietary
OS, devices with limited CPU or memory, or devices that could run a
minion, but for security reasons, will not.
I have a series of RPi's running Raspian which need to deployed in various location around the world.
They will have internet access, but will all be behind a router. Is there an off-the-shelf solution to keep the possibility to create a SSH connection to them? I am thinking about solving problems, upgrading etc.
I am thinking of a 'server' solution where a 'client' on the RPi keep an active connection so a SSH connection can be established when required. Any suggestions will be much appreciated!
I have experimented with several services including LogMeIn Hamachi and Weaved among others. I would highly recommend using Weaved because it allows you to meet your goal (SSH to pi behind a router), and the setup is painless. You may even find some other uses that are quite handy.
See the installation details at https://developer.weaved.com/portal/members/betapi.php
Steps to be up and running:
Go to http://www.weaved.com and sign up.
Install weaved on your pi, and follow the prompts for SSH (Instructions at https://developer.weaved.com/portal/members/betapi.php).
Go to "My Devices" at weaved.com and get the new internet accessible proxy address for your pi.
Enjoy!