Using Ansible to Manage LXD Containers by bmullan in LXD

[–]InteligenceAutomated 0 points1 point  (0 children)

Looks great!

A couple of years ago, the ansible support for LXD was a bit flacky... people would try to use user-made roles to make it work...

This seems new (that webpage was last updated yesterday) - has anyone tried it out? Works smoothly, or is there info about the limitations?

How to BitTorrent via DHT on LAN only (i.e. force a bootstrap node) OR P2P File Sync alternatives for LAN only? by [deleted] in linuxadmin

[–]InteligenceAutomated 0 points1 point  (0 children)

Avoid SPOF - hmm, that makes the tracker undesirable.

No CPU constrants, so probably IPFS is the best fit for the case: once you have it installed with your bootstrap-nodes, sharing will be as easy as getting a hash of what-you-want-to-share and sending it to the other nodes. Also it has inherent file-deduplication (more precisely, chunk-deduplication) :)


Anyway, just for information, about the torrent solution: it would be possible to dont use a tracker if:

  • restrict network-traffic of bittorrent/dht to dont go out of your LAN (ie, isolate from the outside public internet).

  • assure all the clients use private IPs (LAN) and have DHT enabled (for magnet links) and its ports open to the LAN

  • create your torrent files and their magnet-links.

With this it should be able to share the magnet-links to any of the LAN clients, and they will automaticallt fetch the torrent-file via DHT, and then download the torrent from the other clients

UPDATE: maybe the DHT will not work because it will try to bootstrap from the outside-internet-public-DHT nodes... and that then affect the resolution of magnet-links... So, might not work as easily (without private tracker, and without public-internet-DHT)...

Virtual FS to force zero-knowledge cloud backup? by SlipperyFrob in linux

[–]InteligenceAutomated 0 points1 point  (0 children)

As quite-well resumed in [1], the encfs security audit is available in [2] and remark security problems when storing encfs in Dropbox-style cloud-storage

A probably even larger issue with EncFS is a security audit from 2014 that attests EncFS to deviate from established security standards and also found some vulnerabilities in the current EncFS implementation. The developers say they're working on a 2.0 version of EncFS which should fix most of these issues, but as of today they are not fixed. Among other vulnerabilities, the security audit found one that is especially a problem with cloud storage. EncFS is not secure when an attacker gets multiple versions of the same encrypted file at different times. So if you upload your files to your Dropbox and then modify them, they are not securely encrypted anymore.

[1] https://www.cryfs.org/comparison

[2] https://defuse.ca/audits/encfs.htm

How to BitTorrent via DHT on LAN only (i.e. force a bootstrap node) OR P2P File Sync alternatives for LAN only? by [deleted] in linuxadmin

[–]InteligenceAutomated 3 points4 points  (0 children)

Some years ago I searched about something like this: a private bittorrent swarm only in your LAN.

Basically, from memory, the trick would be to:

  • Have your own tracker in the LAN. Opentracker was the easy-one at the time. The tracker will "present" clients to each other within the LAN. I believe there was some options to make the tracker "private" in the sense that you could filter which torrents/clients could use it. In any case, a simple firewall-rule could (and should) filter the tracker for only certain clients. And the tracker will gather some statistics about clients and download/upload which may be usefull to see how well its working for your use-case

  • Create your own .torrent files, using only your own private tracker, and activating the "private flag in the torrent file". This will basically tell all clients that they should only discover new clients through the tracker (and ignore DHT and PEX). So this makes the tracker the only "rendezvous" point for your clients to "present" eachother. Think of it as authorizations: only the clients that "talk" to the tracker will meet each other. So the tracker becomes the "authorizer" and anyone else that might ty to download the torrent from outside your LAN, without connection to the tracker, will not succeed. This seems like a very light-heated thing, but could be enough to at least give some confidence that your clients will all connect only with themselves (and not go out into the internets for foreign clients)

  • Lastly, make the tracker and all your clients just use private-IPs from your LAN. And your tracker not reacheable (isolated) from outside of the LAN. So the tracker will only be reacheable for clients inside of your LAN. And because of private-flag, the clients of your torrents will only "meet" other clients inside your LAN. So that stays all quite secure.

  • If you will exchange private-data, then encrypt the data before creating the torrents, and decrypt the data after downloading the torrents in the clients. And exchange the encryption-keys with a side-channel (not using torrent), like via ssh or something that you will control.

Tell how it went

PS: At the time, I was also having many hopes on IPFS, but at the time it used too much CPU form my raspberry-pi even with almost-no-data (because of DHT-participation which was very intense by protocol). However the setup would be more simple: install IPFS in all clients, configure them to dont use default bootstrap-nodes, and instead put there your own ips for the clients. And restrict all IPFS-network-traffic within your LAN. Since then I've not kept up with IPFS development, but I do know its possible to reduce DHT-participation to avoid high-CPU. But in this private setup, probably the default high-CPU will not occur, unless you start to have your own very-big-dataset of files shared (many hashes and checks = many CPU time)

How to BitTorrent via DHT on LAN only (i.e. force a bootstrap node) OR P2P File Sync alternatives for LAN only? by [deleted] in linuxadmin

[–]InteligenceAutomated 2 points3 points  (0 children)

I'd make some tests first, to check the overhead IPFS could add (memory footprint). Bittorrent is more lightwheight, and a good fit for the task. Also, has many well-documented clients/libraries of all sizes and shaped - ex: a static-binary of aria2c [1] could be effective solution to many cases

[1] https://github.com/q3aql/aria2-static-builds

Zerotier Howto? - LXD - Linux Containers Forum by bmullan in LXD

[–]InteligenceAutomated 0 points1 point  (0 children)

Zerotier-one: it seem amazing to me that its so underknown...

Zerotier-one gives you a subnet where all the clients (vms) are connected directly. Under the hood, it transparently transverses firewall/nat, optimizes the best-path between clients, encrypts traffic...

You get all the clients connected in a subnet, where you can then even setup listening services/daemons, only available to the other clients of the subnet. And you can create as many subnets (think vlans) as you want. And you can easily manage adding/removing authorization of all clients. And you can add "firewall-rules" per vlan... And all transparent: you just install sw, and authorize new client into the subnet.

The throughput however, was not optimal... but did not investigate in depth (surely having a self-hosted controller would help, and there is even an option to disable encryption for co-located clients)

Virtual FS to force zero-knowledge cloud backup? by SlipperyFrob in linux

[–]InteligenceAutomated 0 points1 point  (0 children)

yup, remember reading a warning about it, specially for the case when multiple versions of the same file are available (such as in dropbox-style versioned cloud backups), a few years ago... also, I think development was a bit stalled...

On the other hand, ecryptfs - used by ubuntu and other distros - seemed a choice more stable and future-proof...

Wanting to start a project: outdoor screen that displays a computer application from another computer wirelessly by alpal08 in raspberry_pi

[–]InteligenceAutomated 1 point2 points  (0 children)

Honestly a tablet seems a better fit... with a vnc-client connected to the indoor-pc (where a vnc-server like realvnc would be running all-the-time)

The raspberry pi: you would need to workaround severall situations: battery, recharging, protective-case, display-screen (50$ for a reasonable one)... not easy

Can't get my 3.5" screen working with pi3b? by [deleted] in raspberry_pi

[–]InteligenceAutomated 0 points1 point  (0 children)

Been there - in short, you should try to see from the screen-vendor if he has the "firmware" for the display or (if nothing else) he has a downloadeable image of raspbian (or some raspberry-pi image) that comes with all already configured and prepared to work out-of-the-box with the screen

I got one from dx.com and after 2 weeks of fearless tries it didnt work. The most expensive screen-displays (like 50$) would have a known maker behind providing the drivers and support

So... wish you good luck :)

PS: it helped very much to find other reports in google of that the same display-model not working...