Under Windows XP I have seen some commercial software that protects the computer with a USB device. That is, the screensaver activates after a certain period of time as usual. But to deactivate, you need not only a passphrase, but also a USB device plugged in. The device contains certificates and has to be verified before deactivating the screensaver.
I am looking for some way to implement such feature with Python. I have searched in the Ubuntu Software Center and got BlueProximity being the software most close to my purpose but still different. This software monitors a certain Bluetooth device and its presence is used to simulate user activities periodically to avoid screensaver's activation.
Surely I can do a similar program, periodically check a certain USB disk's presence and validate its containing certificate, and if all-OK, poke the screensaver as some user activity, otherwise lock the screen.
However this is not immediate. Suppose someone have stolen my passphrase to unlock the screensaver, but not the USB disk, then he can unlock the screen. And within at least one minute or so the screen should be locked again. Even if my program has a rather short checking period--like 0.1 second, intervals summing from the 0.1s and the slowly fading time cost(usually nearly 1s) exists between one and another lock-up.
So is there any better solution, such as some APIs that my program can tell screensaver refuse to unlock any way?
You might want to take a look to PAM (Pluggable Authentication Modules). The solution will be more generic, robust and it could be applied to any program that relies on PAM for authentication.
Related
A bit of background on my project: I am doing a robot which can be controlled through the internet with live video feed. For that I have a raspberry pi as an on-board computer that handles the internet connection, video streaming, motor controlling etc. I've been successful with controlling it through a socket connection on python and a public VPS to relay commands (for NAT traversal).
Now I want to implement some sort of "idle state" like you would have on a mobile phone: The robot would stays idle and consume almost no power, and when I initiate a call on my computer it would wake up, stream the video etc. and when I hang up the call it would go to sleep again. Essentially, I want some version of Apple's Facetime and tweak it to my liking. The emphasis is on consuming as little energy as possible, since the robot is battery powered.
I can find almost no information on the internet for such an implementation (or maybe I just don't know the correct keyword). Can anyone point me in the correct direction?
Good morning :)
I have some questions regarding an icecast-setup.
We have my own (Nextcloud)-Server sitting in our church. This works perfectly fine and since here in Germany the community services got forbidden already once during all this Covid19-stuff, we want to have a stream-setup. I managed to set up an icecast-instance on our server and we use my old laptop with Rocket Broadcaster and a Steinberg CI2 to provide the source for the stream. That works all as intended. We already used it once because we stopped public services for two weeks after one of our member got tested positive after he went abroad for a week.
Our operator on the PA doesn't want to have another display there, which would disturb him from listening the sermon.
My project regarding this: I have a RPi4 and a Behringer U-Phoria UMC202HD. The input atm is a standard mic, that is connected to the Interface.
The Pi is configured with darkice and uses its own icecast installation, while I am testing everything at home. Since I started the streaming project, after the service we switched Rocket Broadcaster to use VLC and a folder of old service recordings (mastered and in MP3-format) to provide a source to listen while we are at work or on travels. This option gets used pretty regularly and I want to keep it going.
My plan is to have a little box with a LED levelmeter, where the input level is shown. That should be done with a little python script. Also I want to add two buttons, where presets for the two setups get loaded. Button 1: kill the current source and start the darkice livestream. Button 2: kill the current source and start the playback of old recordings. Both options should have visual feedback for the operator. The raspberry has to work in headless mode without need for a VNC or SSH-connection for the normal usage.
My problem: I tried:
sudo killall darkice && /home/pi/darkice.sh
This code will get changed, because I probably have to use ices for the mp3-playback. So basically it kills darkice, starts the ices playback (for now only restarts the stream in a blink) and vice versa.
The bash-file exists and gets executed at reboot via cronjob. That works well. When I execute the above mentioned killall command, icecast continues the broadcast almost instantly, but the stream stops on the clients. Everyone needs to restart it.
Do I have an option to change the setup, so that I am able to switch between the two options without the need for everyone to restart?
My plan was to create a bash-script, where I do this all inside and execute it via GPIO-input and pythoncode.
Thanks in advance!
I have found a number of answers in pulling information from HIDs in Linux, but not many in Windows.
I have created a system where a person can scan an ID badge when entering a briefing that logs their attendance into a database. It utilizes a Python 3.4 front end which queries and then updates a MongoDB database.
Currently, I have a USB Barcode Scanner which, when scanning, acts as a keyboard and "types" what the barcode says, followed by a CR. I also have a window which takes the text input and then closes the window and executes a database query and update when the CR is received.
The current issue is speed. I have been asked to expand the system so that one computer with a USB hub can take 4-8 of these Barcode Scanners at the same time, attempting to increase scanning rate to 1000 people every 5 minutes.
What I am afraid will happen is that if two scans happen at almost the same time, then their inputs will overlap, generating an invalid query and resulting in both individuals not being logged.
As far as I can understand, I need to place each Scanner in its own thread to prevent overlapping data, and I do not want to "lock" input from the other scanners when the system detects a scan beginning as this system is all about speed. However, I am unsure of how to differentiate the devices and how to implement the system.
Any solutions would be appreciated! Please take note that I am unfamiliar with HID use in this sense, and only have a basic background in multi-threading.
In this scenario I will suggest using scanners/readers that can emulate serial (COM) port. As HID device writes to same bus then there is a huge probability that output from two or more devices could by mixed-up.
More over I will add a device id string to a prefix like dev01. Binding to a com port can be used by pySerial module.
Any comments welcome!
I have very little idea what I'm doing here, I've never done anything like this before, but a friend and I are writing competing chess programs and they need to be able to communicate to each other.
He'll be writing mainly in C, the bulk of mine will be in Python, and I can see a few options:
Alternately write to a temp file, or successive temp files. As the communication won't be in any way bulky this could work, but seems like an ugly work-around to me, the programs will have to keep checking for change/new files, it just seems ugly.
Find some way of manipulating pipes i.e. mine.py| ./his . This seems like a bit of a dead end.
Use sockets. But I don't know what I'd be doing, so could someone give me a pointer to some reading material? I'm not sure if there are OS-independent, language independent methods. Would there have to be some kind of supervisor server program to administrate?
Use some kind of HTML protocol, which seems like overkill. I don't mind the programs having to run on the same machine.
What do people recommend, and where can I start reading?
If you want and need truly OS independent, language independent inter process communication, sockets are probably the best option.
This will allow the two programs to communicate across machines, as well (without code changes).
For reading material, here's a Python Socket Programming How To.
Two possibilities:
Use IP sockets. There are some examples in the Python docs. (Really not that hard if you just use the basic read/write stuff.) On the other hand, sockets in C are generally not that simple to use.
Create a third application. It launches both applications using subprocess and communicates with both applications through pipes. The chess applications must only be able to read/write to stdin/stdout.
This has the additional benefit that this application could check if a move is legal. This helps you finding bugs and keeping the games fair.
You can use Protobuf as the inter-program protocol and read/write from a file each one turns.
You may read the intermediate file every n seconds.
Once you have this working, you may move to use sockets, where each program would start a server and wait for connections.
The change should be small, because the protocol would be protobuf already. So, the only place you have to change is where you either read from a socket or from a file.
In either case you'll need an interchange protocol.
edit
Ooops I misread and I thought it was C++.
Anyway, here's the C support for protobuf but is still work in progress work
http://code.google.com/p/protobuf-c/
I would say just write an xml file that contains moves for black and white. Mark in a separate file who's turn it is and make sure only the program who's turn it is will write to that file to commit their turn.
Here is a link to a proposed xml format for storing your moves that another group came up with
http://www.xml.com/pub/a/2004/08/25/tourist.html
Sockets with a client/server model...
Basically, you and your friend are creating different implementations of the client.
The local client shows a visual representation of the game and stores the state of the pieces (position, killed/not-killed) and the rules about what the pieces can/can't do (which moves can be made with which pieces and whether the board's state is in check).
The remote server stores state about the players (whose turn it is, points earned, whether the game is won or not), and a listing of moves that have occurred.
When you make a move, your client validates the move against the rules of the game, then sends a message to the server that says, I've made this move, your turn.
The other client sees that a turn has been made, pulls the last move from the server, calculates whether where the movement took place, validates the move against the game rules, and replays the action locally. After that's all done, it's now allows the user to make the next move (or not if the game is over).
The most important part of client/server gaming communication is, send as little data to and store as little state as possible on the server. That way you can play it locally, or across the world with little or no latency. As long as your client is running under the same set of rules as your opponent's client everything should work.
If you want to ensure that no one can cheat by hacking their version of the client, you can make the position and rule calculations all be done on the server and just make the clients nothing but simple playback mechanisms.
The reason why sockets are the best communication medium are:
the limitations on cross process communication are almost as difficult as cross node communication
networking is widely supported on all systems
there's little or no barrier-of-entry to using this remotely if you choose
the networking is robust, flexible, and proven
That's part of the reason why many major systems like Databases uses sockets as a networking as-well-as local communication medium.
if both applications running on same computer, use socket and serialize your objects to jsun. otherwise, use web service and jsun or xml. You can find jsun and xml parser in both languages.
How can I detect when a flash drive is plugged in? I'm using a bare Debian installation, without any GUI and want to be notified in my Python script when a new flash drive appears... I know that D-BUS distributes such information, but i dont want to use D-BUS. Is there a more bare access to that information? Shouldn't that be available under /proc or /sys? How can I "connect" to that source?
Bye
falstaff
All mayor Linux distros include udev, that allows you to write custom scripts on hardware events.
You can read uevents from kernel via a Netlink socket and look for events where "ACTION" is "add" (you can also watch if a partition from a device was mounted or unmounted, or if a device is being removed). That's as close to the source of events as one can get in user space. As far as I know, this is how udev detects inserted removable media.
But probably using D-Bus/HAL API via Python bingings will be much easier (no uevents data parsing, etc). Not sure why you are opposed to this. Since you are using Python, I suspect that resources are not really the issue.
If you are targetting an embedded device, then you can run mdev instead of udev.
Then you can write mdev rules that are quite simple and triggers a script.
Of course you are not directly monitoring from your script, mdev is doing it, but you can launch any command. You can probably do the same thing with udev, but it always looked quite complicated to me.
When an USB device is plugged in syslog writes messages concerning this to /var/log/messages. The "dmesg" command shows this log. You can check near the end of the log to see which channel the device was attached to, it is usually /dev/sd(letter)(number) depending on the partitions and number of serial disks plugged into the system.
/proc/partitions shows all the partitions known to the kernel.
I did this using zenity in a script and udev with rule on rhel6 with:
KERNEL=="sd[b-d]", DRIVERS=="usb", ACTION=="add", RUN+="/path/to/script"