rdebath
-
Posts
289 -
Joined
-
Last visited
-
Days Won
6
Posts posted by rdebath
-
-
Okay, peerdrive is a distributed filesystem, your data is stored in a peerdrive volume not on the filesystem. This makes it very difficult to port. It's use of the 'Dokan' library is probably an issue as that 'WindowsFUSE' library isn't being updated and updates were apparently stopped because of unsolvable compatibility issues.
Powerfolder appears to be bound to a server in some rather complex way that allows them to limit what's transferred. They also claim only the "CORE" is open source, whatever that means. (NB: I don't like java either, it tends to make things awkward to run)
Unison is pretty good, but it is a scheduled thing not an update on changes and must have exactly the same version of the application at both ends of a pairing. It used to have a problem with large files; but I think that's been solved by having an option to use an external file transfer program (rsync). (Note: Files are transferred between pairs or nodes, but there can be lots of pairs)
Sparkleshare, yup, what he said.
Oh and the FSF one is very, very, new so developers will be playing with pieces but mostly waiting to see how BTSync turns out.
-
I raised the issue of the birthday problem when the default keys were 128 bits; with that there is a very borderline chance that someone may be able to break something so that there is just barely a chance of a birthday attack within the foreseeable future.
The minimum key was extended to 160 bits and fixed this.
-
Love the idea, especially if any of them has played World of Warcraft.
The simple fact is that Bittorrent is just a file transfer protocol like FTP or HTTP (BTP perhaps
) and is used in EXACTLY the same way by exactly the same people. Nothing has been done with Bittorrent that wasn't done with both ftp and http first.The difference is that it's the fastest and cheapest one in existence. If working perfectly, it will finish transferring the file to all peers at the same moment that an FTP upload to a web host completes. So not only is it faster, but in the simple case Bittorrent has finished before a traditional file transfer has moved a single byte to a peer!
That's the whole reason that Bittorrent is popular with anyone. But it's really popular with the pirate crowd because in low performance modes it costs nothing beyond the internet connection. Higher performance modes can use a "cloud server" to speed up downloads for peers that connect to the swarm late, but they (pirates) don't want to pay for that, still, even 'low performance' is very very quick compared to FTP.
But up to now, Bittorrent has been a pain to setup (torrent files, http servers for trackers, DHT networks getting details) and insecure (no authentication on peers what so ever, encryption, if present, only obscures data from eavesdroppers).
BTSync makes it very, very, easy to setup and secure, all you need is a directory and a 'secret'... Done.
And before anyone asks, yes, it's normal for a company firewall to block the traffic by default and yes it's easy to allow BTSync.
-
Some likely possibilities,
- You've not correctly configured the port forwarding on your NAT box, it needs to redirect external TCP port 8887 to port 8887 on your internal machine. ("DMZ mode" can be used for testing, but that mode also disables all the firewall like properties of your NAT router)
- You have a share currently defined in the config file; for some reason BTSync doesn't start the webui if there are any shares defined directly in the config file.
- There is another firewall messing with you, for example, "windows firewall" will treat connections from the local network differently to those from other networks.
The 0.0.0.0 is the correct IP address to bind the webui to in most cases. Generally, you only change it if you want to restrict where the webui is accessible from. The 0.0.0.0 address means no restrictions and BTSync will accept a connection from anywhere.
PS: Some NAT boxes require a reboot even more often than Windows !!
- You've not correctly configured the port forwarding on your NAT box, it needs to redirect external TCP port 8887 to port 8887 on your internal machine. ("DMZ mode" can be used for testing, but that mode also disables all the firewall like properties of your NAT router)
-
You can use BTSync to sync the container if it's unmounted. BYSync will choose the one with the most recent timestamp and should happily use a block aligned partial transfer. (Not rsync, but good enough in this case)
However, in it's current state, if the container is mounted it's likely that BTSync will consider it's read error to be a deletion of the container and remove the container on the remote system, hence, triggering a full transfer when it can again read the file.
So I would not recommend you use BTSync without carefully backing up all files within the share.
-
I would guess that there was some sort of permission, full disk or disk error on the 'receiving' system.
BTSync still deals very poorly with that sort of thing treating it's failure to make a change as an active user reversal of that change; ie if it can't create a file it pretends a user deleted the file.
Another nasty effect of this is that if one BTSync can't create a file and another can't delete a file they continually throw deletes and recreates back and forth.
Obviously, this is a very poor choice. A better one would be to treat the file as locally ignored.
-
Truecrypt has the problem that it's a container based system and BTSync won't be able to sync the container when it's open.
This will mean that it will have a serious problem if the container is changed on two machines; one or the other will have to win it can't sync at the file level.
Another issue will be that you can't reasonably use SynchTrash (now SynchArchive) because it'll only have whole copies of the container, not small files.
-
NT based Windows uses Unicode (UTF-16 to be exact nowadays) and always has done (Win95/98 can use unicode but don't by default). It converts the 'OEM' and 'ANSI' character sets using somewhat non-standard tables. The US and Western Europe windows ANSI character set is CP1252 which is an extension (or rather several extensions) of ISO-8859-1. The character set ISO-8859-15 does NOT contain all the graphic characters in the CP1252 set (nor does ISO-8859-1)
As I understand it, at the moment the Linux client does nothing with character sets, it's the windows client that converts it's UTF-16 characters to UTF-8 for transmission. I suspect it would be rather complex to add an iconv conversion in the filesystem interface of the Linux client because it would be really difficult to say what should happen when CJK is involved at one end or the other.
As for the other clients, there would probably have to be some complex choices as to the availability of the iconv library and data files (which are NOT insignificant) and a large number of new failure modes for very little gain.
All in all it would be a lot better if you switched to Unicode with the rest of the world and used "luit" for those applications that simply can't be converted at the moment.
But, don't forget to add this to the Wishlist thread.
-
Maybe we should grab the password when the user logs in and use that to decrypt the secret from disk and store it in memory as long as the user is logged in. But that requires some pam magic and needs to be done by an installation routine, so I guess the developers do not feel responsible for that.
This magic is already available in the package ecryptfs-utils. This package allows a user to have a directory (or their entire home directory) encrypted and mounted (fuse filesystem) at logon. None of the files on the filesystem will be available if the user isn't logged in ... if the entire home is encrypted this, unfortunately, will also include the ".ssh" directory with it's "authorized_keys" file.
-
I suspect you'll have to delete the entire ".sync" directory and re-add your shares.
But by all means see if just deleting the file will work first.
-
Local .SyncIgnore files would be easy to understand.
All it means is that a file would be sync'd to ".SyncNowhere/The/file/path.txt" rather than "The/file/path.txt".
Any real file at "The/file/path.txt" would be completely hidden from BTSync.
The optimisation would be that anything that the peer would download into ".SyncNowhere" wouldn't be sync'd until tomorrow ... forever.
With local ignore files like that you'd only have to "Ignore" the files on the peer they were created OR the peer that doesn't want them.
-
Following *.LNK files is VERY unlikely to happen.
For now, at least, BTSync will follow real symlinks on Windows though.
-
In the wish list; currently the only way to do well it is to use encfs.
-
BTSync assumes your Linux machine is using UTF-8 for it's system character set (locale de_DE.UTF-8 or similar).
You really should switch to it you know, otherwise how can you represent a file with a "☺" or a "☢" in the name.
Modern terminal emulators can all do UTF-8. (By definition
) If yours isn't modern I, of course, would recommend PuTTY or Pterm. -
That sort of sounds like some sort of DB corruption, with a memory leak in the error path.
What happens if you try this the below on your *.db files ? (You need sqlite3 installed first)
$ sqlite3 btzero.sync/0FDBBAC4843BCD58A454D2803859501BA27AE32B.dbSQLite version 3.7.3
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma integrity_check;
ok
sqlite> .schema
CREATE TABLE files(path TEXT NOT NULL PRIMARY KEY, data BLOB NOT NULL);
CREATE TABLE meta(hash BLOB NOT NULL PRIMARY KEY, data BLOB NOT NULL);
sqlite> .quit
$
The bold bits are your commands.
PS: ... or you could go look at the other thread ...
-
Actually, it's a lot better than you imagine, you see there are firewall logs in there too. All that yummy randomness donated to me by the dumb script kiddies of the world.
BTW: The kernel takes account of the timing of the disk writes which is a physical process and so subject to some randomness, the actual content can't really be assumed to have more than zero bits of entropy in the general case.
But if you want REAL randomness you need to go here: https://www.fourmila...e_generate.html or here: https://www.random.org/ or here: http://www.randomser...ient/random.php
-
That's not that good.
You are grabbing huge amounts of data from /dev/random when you only need 256 BITS and then you almost throw away a lot of those bits by encoding the data twice. Luckily BTSync saves you by hashing the long string it gets from you down to 256 bits.
All you need to do is this ...
head -c 32 /dev/random | base64
This does usually take a little while to run because Linux very carefully underestimates the amount of randomness available in it's pool. You're probably more than safe enough using /dev/urandom in reality.
Though actually, my preferred method is to provide lots of real random data to a hash command perhaps like this:
cat /var/log/syslog.0 | sha256sum - | xxd -r -p | base64
-
im a little concerned with data storage on mobile devices, and the limitations of flash memory. It's not secure for the same reasons you point out.
You CAN use truecrypt on SATA flash drives.
It is best to allow 'TRIM' through to the device so that the performance of the drive is unhindered.
This has the security disadvantage that an attacker can tell how full the drive is. It is very rare that this is a significant problem.
-
... btsync://ABCDEFG ...
Without the slashes:
btsync:ABCDEFGHIJKLMNOPQRSTUVWXYZ234567
The form btsync://somewhere.com:3000/ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 should be reserved for defining a tracker or known peer (not sure which would be better) or "don't care" if the protocol can cope with tracker requests to a normal peer.
-
Windows Active directory can be used to register applications and the machines and port numbers that these applications (servers) are available on. The data is stored in the "GC".
This sounds a lot like a tracker.
AIUI there isn't normally a cleanup routine for these records so they would have to be timestamped and have the client identifier (so they can be cleaned up when the client returns).
The advantages over a normal tracker are that it's private and doesn't need a firewall hole. Advantage over multicast peer discovery is that it can work on (normal) routed networks between sites and over VPNs.
Major disadvantage is that it's Windows only (especially as it depends on Windows domain authentication).
-
shallowz, You're asking us to fix your multicast routing. I haven't even "fixed" my own, I've already spent more than enough time on it.
Chances are though that it's not even what you want, for performance reasons I would suggest you put a permanent Linux (or NAS) node on each site and only allow intersite traffic to flow between these known nodes. This will reduce the upstream VPN traffic at each site to it's minimum and maximize the speed that a "new" node at each site will get it's updates.
-
You don't "select an interface" for multicast.
Multicast routing is weird, you can't bind to an interface, you always bind to 0.0.0.0 and the routing demon take care of where the packets should (and should not) travel. AIUI if you're not running a multicast router demon the kernel has to assume that all the interfaces are equivalent.
I'm not sure, but I think Windows uses the "first" interface; you can reorder them by looking at your interfaces in Explorer and Selecting Advanced->Advanced. Linux OTOH I think just uses the default routing table, so "ip route add" is the right solution if you don't want to run a proper routing demon. (IPv6 is different because Link local scope has to work.)
I suppose you're actually thinking more of local broadcast, sending the packets to 192.168.1.255. It's a lot easier, but, in theory, not as versatile. In practice there are several multicast routing protocols and none of them always work, so normally there's little difference between multicast and local broadcast.
For practical firewalling, just block multicast from leaving or entering your "organisation" and don't bother logging it.
Oh, and be careful when mixing NAT and bridging, iptables will see packets going across the bridge and you don't want to NAT multicast packets by accident.
-
Sounds like your "geode" processor doesn't have enough features for the compile options they use.
$ cat /proc/cpuinfo
kos13 do they compile with an "--march=i686" option ? That might cause this.
Though if the old machine version isn't compiled the same that might imply an OpenSSL bug or a bug in your selection of acceptable encryption/hashing modules.
NB: I still want a version to run on my woody machine ie: i486 static ELF.
-
Um; I think the MDMP file you've posted is a Windows dump file; can't tell for sure though because it is empty, just a header.
Debian is usually setup with core dumps disabled ie:
$ ulimit -c
0
$You need to enable them before you'll get a linux core dump ...
$ ulimit -c unlimited
$ ulimit -c
unlimited
$This only applies to the shell you run the ulimit command on.
) and is used in EXACTLY the same way by exactly the same people. Nothing has been done with Bittorrent that wasn't done with both ftp and http first.
Crude python script to create your own key
in Sync Stories
Posted
You're converting the hex to base32 'incorrectly'. Simply if you're taking the bits from the hex and reencoding them as base32 it should be 4/5 the size of the hex. It looks like you're taking the hex as ASCII bytes and encoding that instead.
'Correctly' ..
Start with the string "cats"
The SHA1 in hex is "8ebf601f8b808c32b8d2fb570c2e0fbdbb388add"
The SHA1 in base32 is "R27WAH4LQCGDFOGS7NLQYLQPXW5TRCW5"
Put that into BTSync and get ... cats.
NB: http://www.debath.co.uk/MakeAKey.htm ALL in javascript.