When trying to connect to Azure Sphere using the provided azsphere_connect.sh, we get an error, as below:
$ sudo ./azsphere_connect.sh -v VERBOSE: Looking for attached Azure
Sphere devices VERBOSE: Found attached Azure Sphere device at
/dev/ttyUSB2 VERBOSE: Setting up SLIP connection ERROR: Could not
establish SLIP connection.
This has been acting like this for a few months. The only workaround I found was to patch net-tools/slattach to support the higher speeds required by Azure Sphere and use that instead.
Currently, the only supported Linux distros are Ubuntu 18.04. Are you seeing this error if you are using Ubuntu as well?
Here's the link to documentation - https://learn.microsoft.com/en-us/azure-sphere/install/install-sdk-linux#prerequisites
Related
Please please help in setting up Turn server in Ubuntu, such that we can have video call even connecting from different network.
I have installed using below command in Ubuntu 20.10 :
sudo apt-get install Coturn.
Can any one suggest how I should configure turn server to achieve above mentioned issue.
You should start looking at the example configuration.
Adapt it your your needs (host public IP address and realm), then restart coturn.
Then you can test it with tools like test.webrtc and WebRTC sample for Trickle ICE (or your own client application).
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
Is there an emulator or any suggestions for setting up developer environments with IoT Hub. Having a single IoT Hub in our dev environment shared by all our developers is problematic because messages from each developer are handled by all developers. Setting up unique IoT Hub instances for each developer is also problematic because of the local configuration changes required to connect to each IoT Hub.
An Emulator would be AWESOME! but if that's not available some other way to segregate traffic per developer would be extremely useful.
Regards,
Eli
I'm afraid there's no Azure IoT Hub emulator yet.
If by emulator, you're talking about something like a local server and keeps all the storage in the local RAM or HDD, this might sound like a good idea.
However, when you think about it, it's no easy task for such emulator. Under the hood, we're talking about multiple communication protocol support(http, mqtt, ampq, etc), custom gateway support and seamless integration with other Azure offerings like Stream Analytics, etc...
Not saying it's impossible, but it's complicated.
Anyway, if you want to keep away from receiving unwanted messages from IoT Hub, there's some workaround you can try for now. For example, with mqtt protocol, you can subscribe to some so-called "topic", identified by unique "device id".
If you look forward to having a minimum IoT Hub emulator, go ahead an open up a request in the Azure IoT Hub user voices.
There are few solutions to ease contention when using a single hub. Here are two suggestions:
(Recommended) Unit testing - instead of relying on live data and connecting to a real hub structure your code in a way that you can debug and test it using test input. It usually requires only one layer or separation. For example: http_trigger_azure_function calling a piece of code that can be called from a unit test.
If you structure your code this way the Iot Hub specific code should be minimal.
When using a shared hub you could use custom routes so that only telemetry from developer A's devices goes to developer A's consumer.
Official Azure IoT EdgeHub Dev Tool
The Azure IoT EdgeHub Dev Tool provides a local development experience with a simulator for creating, developing, testing, running, and debugging Azure IoT Edge modules and solutions.
The simulator allows you to run, test and debug your own custom IoT Edge modules locally, without the IoT Edge Runtime, and with the following benefits:
Your custom Edge module code is the same whether running on the simulator or the full IoT Edge Runtime.
Your Edge solution can be run locally without the need to push new images or create IoT Edge deployment manifests.
The only credential required to run your Edge solution on the simulator is the IoT Edge Device Connection String. The IoT Hub Connection String is not needed.
It helps you debug your custom Edge modules on the host and not just in the container.
The following table compares the requirements to run your solution on the IoT Edge Runtime and iotedgehubdev tool:
IoT Edge Runtime
iotedgehubdev
Device Credential Needed
YES
YES
IoT Hub Credential Needed
YES
NO
Build Image
YES
YES
Push Image
YES
NO
Create Deployment
YES
NO
Support native debug scenario
NO
YES
Installing
Install Docker CE (18.02.0+) on
Windows, macOS or Linux
Install Docker Compose (1.20.0+) (Linux only. Compose has already been included in Windows/macOS Docker CE installation)
Install Python (2.7/3.5/3.6/3.7/3.8) and Pip
Install iotedgehubdev by running the following command in your terminal:
pip install --upgrade iotedgehubdev
Note: Please install iotedgehubdev to root on Linux/macOS (Don't use '--user' option in the 'pip install' command).
Please make sure there is no Azure IoT Edge runtime running on the same machine as iotedgehubdev since they require the same ports.
Quickstart
1. Setup
Windows
iotedgehubdev setup -c "<edge-device-connection-string>"
Linux/macOS
sudo iotedgehubdev setup -c "<edge-device-connection-string>"
2. Start/Stop an IoT Edge solution in simulator
Windows
iotedgehubdev start -d <path/to/deployment-manifest>
iotedgehubdev stop
Linux/macOS
sudo iotedgehubdev start -d <path/to/deployment-manifest>
sudo iotedgehubdev stop
3. Start and debug a single module natively
Start the module with specific input(s) and/or environment variable(s)
Windows
iotedgehubdev start -i "<module-inputs>"
// OR
iotedgehubdev start -i "<module-inputs>" -e "<environment-variable>"
Linux/macOS
sudo iotedgehubdev start -i "<module-inputs>"
// OR
sudo iotedgehubdev start -i "<module-inputs>" -e "<environment-variable>"
For example:
iotedgehubdev start -i "input1,input2" -e "TestEnv1=Value1" -e "TestEnv2=Value2"
Output the module credential environment variables
iotedgehubdev modulecred
Start your module natively with the environment variables from the previous step
Send a message to your module through the RESTful API
For example:
curl --header "Content-Type: application/json" --request POST --data '{"inputName": "input1","data": "hello world"}' http://localhost:53000/api/v1/messages
Stop the simulator
Windows
iotedgehubdev stop
Linux/macOS
sudo iotedgehubdev stop
Other resources
Azure IoT Edge for Visual Studio Code
Azure IoT Edge Dev CLI Tool
Data/Telemetry
This project collects usage data and sends it to Microsoft to help improve our products and services. Read our privacy statement to learn more.
If you don’t wish to send usage data to Microsoft, you can change your telemetry settings by updating collect_telemetry to no in the ini file.
Concerns
While our friend commented he is worried the official link changes, I am hoping the official Microsoft's repo link on GitHub never changes (unless while it still useful). At least, I dont know how other way I can post binary files here.
Here is the repo https://github.com/Azure/iotedgehubdev
Cheers To everyone
What is the best way to develop with open shift origin? Is it using vm or install it locally? I have tried installing the vm and I could not login to the vm. What is the default credential used to login to fedora vm.
Default credentials
Depending on which route you follow (see below) there might or might not be real authorization in place.
If you have the AllowAllPasswordIdentityProvider in place you can get away with test/test or whatever.
If you take the binary version (see below) this is what you'll have by default. I changed it to be HTPasswdPasswordIdentityProvider instead.
For the other options I think you will have a user called system, with the password admin coming with the setup.
Docker container version
You can quickly get OpenShift running in a Docker container using
images from Docker Hub on a Linux system. This method is supported on
Fedora, CentOS, and Red Hat Enterprise Linux (RHEL) hosts only.
Link: https://docs.openshift.org/latest/getting_started/administrators.html#running-in-a-docker-container
As per the origin folks, this setup is not (yet) a full example, but very easy to get started with. You should be able to follow the instructions to get an all-in-one instance up and running in no time. However, this approach cannot teach you how to create a cluster (master(s) and node(s))
Vagrant VM
This image is based off of OpenShift Origin and is a fully functioning
OpenShift instance with an integrated Docker registry. The intent of
this project is to allow Web developers and other interested parties
to run OpenShift V3 on their own computer. Given the way it is
configured, the VM will appear to your local machine as if it was
running somewhere off the machine.
The OpenShift Master, Node, Docker Registry, and other pieces are running in one VM. Given it's focus on application developers, it should NOT be used in production.
Link: https://www.openshift.org/vm
Binary option
Red Hat periodically publishes binaries to GitHub, which you can
download on the OpenShift Origin Releases page.
Link: https://github.com/openshift/origin/releases
This is the option I follow currently. You download the binaries, install GO, then setup the OC client tools. Next step you generate the configuration files and start adding your system components (router, ...).
Follow this page to understand the basics:
Link: https://github.com/openshift/origin/blob/master/examples/sample-app/README.md
Ansible route
For production installation you probably want to install your cluster via Ansible.
My humble advice is to do this once you got a bit of an experience via configuring by hand (see previous point). Let's hear some people with more experience though.
Link: https://docs.openshift.org/latest/install_config/install/index.html
Documentation in general
Link: https://docs.openshift.org/latest/install_config/master_node_configuration.html#creating-new-configuration-files
Spin up a Centos.7 VM, download the latest origin tools:
wget https://github.com/openshift/origin/releases/download/v1.3.0-alpha.2/openshift-origin-client-tools-v1.3.0-alpha.2-983578e-linux-64bit.tar.gz
tar xzvf openshift-origin-client-tools-v1.3.0-alpha.2-983578e-linux-64bit.tar.gz
ln -s /root/openshift-origin-client-tools-v1.3.0-alpha.2-983578e-linux-64bit/oc /usr/local/bin/oc
chmod 755 /root/openshift-origin-client-tools-v1.3.0-alpha.2-983578e-linux-64bit/oc
Bring up your single node origin cluster:
oc cluster up --use-existing-config --host-data-dir=/var/tmp/etcd
Login using the instructions provided.
We wrote a small prototype web app using Pharo and Seaside and we want to now demonstrate to the suits that the app can be deployed into our standard Linux build. We use a mix of CentOS, Ubuntu Server and Gentoo which are run headless since most of our apps are JAVA/Apache based. Only port 80 and 443 are open to the outside world.
What are your experiences when hosting Seaside/Smalltalk server side apps?
it runs great, btw you can get free hosting for your seaside app at:
http://www.seasidehosting.st/
for more power you'd need your own server of course...
some benchmarks here:
http://gemstonesoup.wordpress.com/2007/10/19/scaling-seaside-with-gemstones/
The Seaside Book has a chapter on deployment. It describes how I typically deploy a Seaside application.
I just use a ssh tunnel to get the X display on my local machine. I'm using slicehost (US) from the Netherlands, so I have a ping time of 135 ms. That's not that nice, but ok.
Next step will be Lukas Renggli's remote frame buffer package to use a vnc viewer.
Let's see what Miguel Cobá had to say about it on it on the Gemstone mailing list:
If you have already installed a RFB in your machine then use it.
If you have RFB installed in your image and it is accesible from your
client machine, use it
But, both of them are unencrypted. If you want to encrypted you must
setup a tunnel (maybe with ssh or maybe TLS).
I think that that is redundant because you must use a tunnel and then
the RFB. So what I do, in linux is to install the minimal X libraries
and then forward the X session to my local machine.
In the server (Debian/Ubuntu instructions):
aptitude update
aptitude install xbase-clients
aptitude install xtightvncviewer
Test it from the client machine:
ssh -X remote_server
squeakvm gemtools.image &
This will start the squeakvm process on the server, but all the graphics
will be shown on the local machine (the Xserver for this particular
scenario).
Also, if you install RFB on some of your images and start them headless,
you can use xtightvncviewer to connect to inside the image through the
RFB server.
ssh -X remote_server
xtightvncviewer localhost:0 &
this will run the xtightvncviewer on the remote server but, again, will
show on your local machine. Supposing you have your image in the remote
server running RFB in the first display.
Which is the advantage:
- You don't have to open ports for RFB on the remote server
- You transmit everything encrypted through ssh
- You only run the commands on demand in the remote server. You don't
have to have VNC running always.
- You can configure your RFB in the image to accept only localhost
connections and not from everywhere.
Martin McClure adviced me to take a look at NoMachines NX (less chatty X),
but that's still on my todo list.
For another set of deployment instructions, take a look at Miguels blog
The blogosphere's been talking about this issue recently.
Doug Putnam wrote up his experiences in installing Seaside (on Pharo) on his Slicehost slice, working off James Robertson's writeup (which uses VisualWorks, I suppose?).