Posts by chewitt

    Although they may claim otherwise, the other user activated SSH during install which hardcodes it into syslinux.conf and this disables the normal on/off capability in the first-run wizard and settings add-on. From the next alpha build (7.90.008) the ability to force SSH has been removed as part of a general cleanup of the installer.

    NB: If it is forced on, one reason for not being able to connect is an old (out of date) PuTTY version which is trying to use cipher suites that we no longer support in the SSL versions we use.

    GitHub - LibreELEC/LibreELEC.tv: Just enough OS for KODI <= our collection of prior art

    Add-on development is one of those things where the chances of success are proportional to the amount of help you need to ask for. The build system has a ton of existing packages. It's probably missing a few things needed for OpenHAB to work, but the structured format for a package is documented in packages/addons and that's really all the help we can offer - unless you have specific Q's about compiling/linking.

    The lack of documentation is partly deliberate as it acts as a noise filter. My 5+ years experience with LE/OE shows developers who will succeed at the task might ask for a few pointers but existing content is all they need to create something. The developers who seek tutorials and how-to guides are missing the skills to succeed and usually end up asking us to write things for them, which we're not really staffed for.

    It's best to understand that you're using a tethered hotspot (as you'd find in a mobile phone) not an access point; it works as-is and there is no option to reconfigure anything, i.e. make it work like a wireless bridge. That said, devices on the WLAN segment should be able to access services on the Ethernet segment of the network by IP address without issues, but you probably don't have local 'name' resolution which would requires broadcast traffic to be routed over all subnets. As the WLAN segment is behind NAT you'll need to create static routes to have anything on the LAN side contact WLAN devices. If you want anything more than how it is, it's time to $pend and get a proper access point (or bridge).

    The correct approach will be to create a udev rule that triggers a bash or python script when removable media is mounted. The script needs to scan the device for playable files and create a Kodi playlist in .xsp format. You can then run a kodi-send "PlayMedia" command to instruct Kodi to play the playlist found at /path/to/playlist.xsp, and then when finished you can use kodi-send "ClearPlaylist" to remove it from Kodi.

    The add-on for 8.0 builds should appear in the repo soon. It's probably not perfect as-is, but as long as people intelligently report issues we (mostly Anton) will figure things out and push updates quickly.

    This sounds like a timing/sequencing issue. Set a 20 second "wait for network" (which should be renamed someday) startup delay on Kodi and then see if the cards have loaded drivers etc. before Kodi (and thus TVH) starts. If that works you can tweak the delay value down.

    It's technically possible but not going to happen in core images. You can use @vpeter's LAMP add-on which includes MySQL (or MariaDB, I forget which) server, or on most LE images you can install the docker add-on and deploy a MySQL container.

    1. The packaging of LE/OE ultimately prevents this issue being solved. The OS password file is inside a read-only compressed file. If you can figure out how to write to things inside the read-only file, we welcome the PR on GitHub. The compromise to minimise attack surface (in the context of 99%+ installs being domestic behind router NAT/firewall and without IP/port forwarding) is that SSH access is off by default. We also advise users NOT to expose LE directly to the internet.

    2. In LE/OE a malicious add-on has root access to the OS and can do what it likes. This is partly a failing of Kodi (no sandbox) and partly a failing of LE (where everything runs as root). Neither situation is likely to change in the medium-term and if you have root/admin access to any OS (Win, Mac, Linux, even ye olde OS/2 warp) there are enough binary OS tools for any competent attacker to wreak havoc; we are not unique. There are current examples of add-ons that maliciously attack other add-ons (pirate stream repo's trying to break their competitors). There are also examples of add-ons that take content from the local system and upload it to torrent networks without asking. I am not personally aware of examples of anything that co-opts the box into a botnet, but it is technically possible; hence Kodi Krypton has a new feature to auto-block the installation of add-ons from zip files (which is how you install pirate repo installers which host dubious add-ons) unless you opt-out. In the long-term there are thoughts on how to sandbox things, but that's a complex discussion. TL/DR; be careful what you install and where you install it from, same as every other OS.

    3. As per #1, keep SSH off unless it's being used, use key-auth not password auth, and do not expose/connect the box directly to the Internet.

    NB: Shodan searches reveal a small number of fcukwits who have exposed the SMB or UPnP shares of their LE/OE boxes to the Internet. It's hard to say how that correlates to the number of SSH exposed systems there are without actually self-scanning for them (and I'm not Brian Krebs) but from the number of SMB systems I believe the number is not statistically significant enough to represent a worthwhile/economic opportunity for the actors who perpetrate these attacks; they are normally looking for "low hanging fruit" that provide much larger device counts. This is obscurity not security but it still counts, sort of. On the positive, I have been periodically checking the LE/OE system count via Shodan for some time and the number has not grown proportionally with the size of either project's installed base. I can also assure you that both LE and Kodi teams take security and privacy seriously; both teams have vocal people with professional security credentials on their staff.

    WPA2-Enterprise should be supported but the GUI for configuration was never implemented in our settings add-on as the developers in the team who created the add-on never had access to such a network to test with (not very common in domestic scenarios). If you do things under the hood it should be possible to use; but this will require you to experiment. Start with "connmanctl" .. something like:

    connmanctl
    agent on
    scan wifi
    services
    connect <name of service> <= tab autocomplete works here

    When you connect to a normal network it asks for username/pass when connecting. I've never had an Enterprise network to test against, but maybe it asks you for all the required information. If yes, please report back :)

    If not, have a look at Talk:Wireless network configuration - ArchWiki and Google for other examples of configuration and do some experiments. We store connman service configuration in /storage/.cache/connman/

    NB: You will of course need an SSH connection via Ethernet to set this up. It's no issue to have two active connections; Ethernet takes precedence.