nils

Members
  • Posts

    238
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by nils

  1. /dev/random can block if it does not have enough entropy i.e. sources it uses to create pseudo-random numbers. /dev/urandom will not block, which could in theory lead to sequences which could be cracked - if knowledge of the system is available to the attacker. As this is highly improbable /dev/urandom can be used, see http://stackoverflow.com/questions/3690273/did-i-understand-dev-urandom

     

    @dmason: thank you for the commandline version to generating new secrets :)

  2. Whilst BTsync is not out of beta, I would recommend to make one or multiple backups of anything you want to test-run through BTsync. 

    Once you have that, you can test it out.  BTsync should not write anything to the db-files in your shares if it is the only master-node. The RO-nodes might get corrupted, as BTsync on the master-node will synchronise without caring about other processes accessing the files.

  3. Hello,

     

    There has been a similar thred in this forum about changing the web interface, specifically the icon and name shown in a browser. The user however found out, that by restarting BTsync, all the changes were overwritten again. The developers distribute the webui within the binary file and do not currently allow permanent changes to it as far as I can tell. Maybe it is worth waiting for an API, which could (probably) be accessed via PHP. 

  4. Hello,

     

    First of all it seems that WiFi and ethernet at your workplace do not have the same subnet and/or firewall config, otherwise you would be able to access your local printer from your WiFi. 

     

    Secondly torrent clients do not by default need to have NAT/UPnP enabled or allowed by the firewall/router to function. BTsync on the other hand needs to "poke" holes through your firewall in order to work, either by someone setting up port forwards in the firewall or by using UPnP, which needs to be allowed by the firewall, otherwise clients cannot find each other.

     

    Possible remedies are talking to the admin at work or setting up a VPN (if the firewall allows those). HTH

  5. If one wants to have less shares to maintain, symlinks are not a bad option IMHO. Let's say a user has several software packages and their configs - for whatever reason - all reside in different folders. Now syncing all these configs to a NAS as backup is a pain if each one has to be set up as a single share, so by using symlinks, everything could be synced in one single share. but YMMV

  6. Permissions will get garbled up. The reason is simple: On Mac1 BTsync runs as Administrator and has - based on its privileges - access to all user files. That's good because that is what you want. It does not however care about ownership, maybe some access rights like writeable and executable. On Mac2 BTsync runs as Administrator as well, waiting to receive the files and saves them under its own username and therefore effectively kill the ownership settings. BTsync is multiplatform, so the whole bunch of Unix/Linux clients would not bode well if they cared about ownerships when paired with Windows clients.

     

    What you could do instead is syncing shares on the user level, which would allow User on Mac1 to sync to User on Mac2. Although I think some extended attributes won't make the sync either and could break some other stuff. Maybe some other sync solution would be more suitable for your use case scenario e.g. rsync.

  7. A daemonized version for all systems (where possible), including the webui OR make desktop versions headless capable with commandline switches and a webui.

     

    OS X specific wish (minor bug?): Closing of the window (Open Bittorrent Sync) with cmd+x would be great.

  8. So far the OS X version is a GUI version only and no separate daemon version is available, similar to the Unix and Linux version.

    What you could try:

    1)  DL the OS X version on your headless server and cd to the directory BitTorrent Sync.app/Contents/MacOS. Try to run the Bittorent Sync binary and see what happens, maybe try commandline options.

    2) use virtualbox on the commandline, create an image for linux and run btsync inside.

    3) make a feature request (as you did already on the wishlist) and wait/hope for such a version.

     

    HTH

  9. The desktop clients support setting up specific ip addresses/hostnames with ports. If you use those and disable relay and tracker, you have your own tracker, circumventing the ones set up by the btsync crew.

    Edit:

    Of course this means you need to have either a fixed IP address at this node or something similar to dyndns/noip setup as well as access to port forwarding of firewall configurations to allow communications for the specific UDP port if necessary.

  10. UC4 is available in the iOS version, where you can select files to be sent to another mobile device from the photos and shared folders on the client. What happens behind the scene probably works this way:

    1) copy selected files to temp folder

    2) create new share on the iOS client using the temp folder

    3) generate link/QR code

    4) other mobile grabs the QR code and connects

    5) leaving the screen deletes the share and the temp folder.

    The QR code secrets are already quite neat with a format like btsync://<your secret here>?n=<your share name here>

    edit:

    "all" that is necessary would be porting this to the desktop version and you would have instant file transfer through btsync

    UC3 will probably never make it into btsync, because as soon as you even have a one time secret, that person can make a copy of the shared folder upon sync completion, without you knowing it. If this will ever be realised, then with btsync as backbone through an API used in a 3rd party program.