Search Criteria
Package Details: doorpi 3.0beta2-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/doorpi.git (read-only, click to copy) |
---|---|
Package Base: | doorpi |
Description: | VoIP-based door intercom station for Raspberry Pi |
Upstream URL: | https://www.doorpi.org |
Licenses: | CC BY-NC 4.0 |
Submitter: | wuestengecko |
Maintainer: | wuestengecko |
Last Packager: | wuestengecko |
Votes: | 0 |
Popularity: | 0.000000 |
First Submitted: | 2018-11-06 00:35 (UTC) |
Last Updated: | 2018-11-20 02:50 (UTC) |
Dependencies (9)
- python (python37AUR, python311AUR, python310AUR)
- python-requests
- git (git-gitAUR, git-glAUR) (make)
- python-setuptools (make)
- python-picameraAUR (optional) – Take and mail snapshots; stream video
- python-piface (optional) – Use Piface IO expander
- python-pyserial (optional) – Use serially connected peripherals like RFID
- python-raspberry-gpio (optional) – Use onboard GPIO header
- python-watchdog (python-watchdog-gitAUR) (optional) – Use files as virtual IO pins
Latest Comments
wuestengecko commented on 2019-03-08 19:05 (UTC)
Thanks for your feedback @BertVoegele, and sorry for not coming back to you sooner!
The reason I originally removed the gpio group in this package was simply that I didn't know (yet) how to set all that up. Both
PrivateDevices
andProtectKernelTunables
are in fact required to be false for GPIO to work, which I have fixed, but I'll tag a new release only after the pjsua2 client works again.You shouldn't need anything special for virtual pins except some writable place, which should exist at
/run/doorpi
(this was in fact how the majority of my testing took place without me noticing physical GPIO was unusable by default).BertVoegele commented on 2019-02-11 12:53 (UTC)
Thank you for making the package available here. Please consider easing up hardware access for the dynamic user by leaving "gpio" respectively by adding "spi" to the "SupplementaryGroups" entry, and by setting "PrivateDevices" to "false". The latter one is required by devices using SPI (e.g. the piface boards) - as are the groups apparently. Setting "ProtectKernelTunables" to "false" does allow for access to file-based (aka virtual) pins.
If inclined to include video streams with the SIP session, also adding the group "video" to the "SupplementaryGroups" seems to be a logical conclusion - however, that I didn't test.
Lastly a security concern : please also consider making the socket available only for either localhost, or for IPv4 (as NAT'ed subnet can be assumed given the application's use case). With the current setting, the socket for the web interface will also happily bind to any available IPv6. Including those with scope global, which probably is not intended by the casual user.