I'm developing an embedded linux application & it uses egt as the GUI front-end. The GUI uses wpa_supplicant to connect/ register WiFi network. I've got the same GUI application running on my desktop for development purposes.
Accessing wpa_supplicant (e.g. wpa_ctrl_open) isn't an issue on the actual embedded device as it runs as root, but on the desktop I'm running into permission errors. I don't want to run the GUI application as root on my desktop in case it trashes my system.
So whats the proper way to run wpa_supplicant as non-root?
Many thanks,
All credit goes to Klaus D. for the correct answer. As he suggested the issue as the permissions on the sockets. Initially I only changed the permission of the actual socket (i.e. WiFi interface) but the actual containing folder needs to be set correctly also (i.e. var/run/supplicant).
Thanks Klaus & hope this helps someone else.
Related
The SDKs at https://www.bloomberg.com/professional/support/api-library/ allow you to connect to localhost 8194 to fetch data. Please correct if any of the following is incorrect:
The use of the SDK requires the installation of a Terminal software on the PC where the program using the SDK is being run.
The Terminal software creates an endpoint listening on port 8194 through which the data can be fetched.
Question:
Is it possible for another computer in the local network to run the SDK and connect to the computer that hosts the Terminal service?
Does the Terminal service license support such use wherein the data leaves the PC and gets pulled to a different PC?
Regards
No, it is not technically possible to connect to another PC which is running the Terminal and even if you can get around this it is not allowed by the license. Data downloaded on a PC running the Terminal must stay on that PC.
Bloomberg offers 2 solutions which don't require the Terminal to run and do require authentication: Server API (SAPI) and B-PIPE. To clarify, because you're describing having to run the Terminal on the PC you're necessarily talking about Desktop API.
Which options do we have to do automated UI testing on remote computers connected via RDP, if I don't want to install anything on the remote computer?
My only idea is to open the rdp session always in the same way and use recorded mouse and key strokes, but there are some disadvantages, e.g. I assume it's slow?
Anyways, do you know any open source or proprietary tools I can use? Best would be that I have to install nothing on the remote machine and play the record on my local machine.
Starting with UFT 11.50 (previously known as QTP) there is support for image based testing.
You can have one machine with UFT installed and replay on other machines via RDP using Insight UFT's image based automation solution.
eggPlant Functional allows you to automate the UI of any app on Windows machines using an RDP connection. It's pretty fast assuming you are connecting over a decent network, and you don't need to install anything additional on the target machine.
I have written an application using ALSA (snd_pcm_open, snd_pcm_readi, etc). The application works perfect locally on my machine. However, when I SSH to another machine and run it through the SSH connection, all calls to snd_pcm_open fails with a message "Device does not exist" or similar. The remote machine has a soundcard just as my local machine has.
What could be the problem here?
Thanks!
EDIT: If I run the application using the console on the remote computer (walk to the computer, login, run the application), the application runs fine.
The problem might be with /dev/snd/* access rights.
Be sure the user is in the audio group.
In my case, I had to do adduser $USER audio, disconnect and then reconnect.
Just to check for the obvious: Are the drivers for the sound card on the remote machine loaded and working correctly? Check /proc/asound/cards and see so that the card is listed.
Just to confirm...you have the application installed on the remote machine and the remote machine has otherwise working aplay etc? The remote machine must be set up so that if you were to login from the console and run the application, it would work
If this is the case then check your environment variables as sometimes they can be subtly different.
Found the reason. Turns out /dev/audio and the devices below /dev/snd/ where all owned by the user logged in on the remote computer, and readable/writable by no one else. For testing I applied chmod 777 /dev/audio /dev/snd/* and it started working.
Anyone know how I can apply a bit more generous permissions to the audio devices for the remote computer (which will last after a reboot)?
I want to kick myself to learning network programming, starting with implementing existing network protocols. I've finished the (rudimentary) design and will start coding soon. The problem I haven't been able to figure out solution to is related to testing: I only have one Windows laptop running Windows 7 Pro with only a recovery disc (no installation disc) that obviously cannot be used on a VM.
Hard-coding input/output data clearly isn't a good way to test any sort of program. So, what solutions can I look into?
Thanks for your time.
P.S.: In case this matters, I'll do the coding in C++.
You can run a client and a server on the same machine. When accessing the network layer, just use the local callback loop (127.0.0.1 for ipv4 or ::1 for ipv6) to connect to your server when you run the client.
If you provide the APIs that you will be using (wininet, APR, Boost etc) a more detailed answer would be available.
What about a VM with Ubuntu or some other distro of Linux?
I'm looking for a way to allow potential customers to try my application before they buy it.
The product is a windows forms application that requires an SQL Server database to operate.
Although I have a functional demo that the customer can install on their network, I want to make it easier for them by have them "play" with it at my environment.
I remember Microsoft had (has?) something similar. I was testing Visual Studio a few years ago in a virtual environment where I was connecting to a server at Microsoft.
They setup the environment this way so when a user logs off after using it rollback his actions. Or to explain it better: when a user logins it starts with a new, clean environment.
So any projects I've created testing Visual Studio were lost after I logged off.
Any suggestions?
Thanks.
Some solutions that come to mind:
Provide remote access
You could provide access to a running instance of your application via some sort of remote connection protocol, e.g. via RDP or via VNC.
For example, there is a Java VNC client which can run as a Java applet; you could put that on a webpage and have it connect to a VNC session you host on your servers.
Or use Windows Terminal Server, and allow connection via RDP.
Both solutions of course have the drawback that people need to open the appropriate ports, if they are behind a firewall. There might be ways around that, however (e.g. you can run VNC over HTTP).
VM image
A completely different solution: Provide a ready-to-run VM image (for VMWare, VirtualBox or similar) of your application, including server and everything. You would need a demo version of your app though, plus getting redistribution rights for all the proprietary components (Windows OS, SQL server) might get hairy.
Offer videos
Often people do not really need to actually use the app; they are mainly interested to see how it works. So maybe it is enough to host videos of the app in operation. That allows you to put in some advertising for your features, and lets you show the users what they might miss when testing on their own.