On Sun, 20 Jan 2019 12:12:53 -0000 (UTC), Dan Purgert wrote:
> You would have a better time of things by using a server with the
> "master(tm)" copy, as the main problem with any manual-update based tool
> is remembering to send the file to the other devices.
Hi Dan,
I agree with you that a "master" passwod.kdbx file makes sense.
(A copy is fine also ... where it's only a minor philosophical difference.)
The three approaches, as I understand the problem set, are:
1. Maintain a local (partial) copy of the master passwd file on each device
2. Maintain a Master passwd file on some kind of local cloud share
3. Same as #2 with the only difference being it's a copy of the Master file
All three approaches hinge on the ability to pass "a file" back & forth.
Since Apple products generally have the most cross-platform issues,
I've tested the non-Apple products & only have a problem with Android.
That is:
a. Linux can use smbclient to copy the passwd file from a Windows share
b. Windows can use "copy" to copy the passed file from a Windows share
c. Android _should_ be able to do the same thing but fails.
Right now I'm trying to figure out why Android can't access a Windows
network share using either the SyncMe Wireless or AndSMB clients.
> Nextcloud / Owncloud (or similar "cloud storage" software that has sync
> clients for all* platforms) is a relatively easy solution to that
> problem. If you didn't want to include phones, cronjobs would be
> perfectly fine as well.
Networking is a LOT easier if we ignore the mobile devices.
But they are critical to the problem set.
The main problem, as I see it, with NextCloud/OwnCloud, is what we
discussed earlier this week about needing a 100% Linux server.
Yes, with heroics, they can be made to work on Windows, but it's my
understanding that you literally must be an expert to be successful.
If folks disagree, then I'll simply ask them for the exact steps, so that I
can cut and paste them, to get them to work on Windows.
A viable option, of course, is a $35 Raspberry Pi that can act as the
full-time Linux server - but that takes expertise also.
> * Well, Owncloud has windows / linux / mac / android / iOS.
We have to differentiate between *servers* & *clients*.
The _client_ is never the problem when owncloud solutions are discussed.
The problem is the server.
It's my understanding that the only viable server is a Linux server.
that means Linux has to be running 24/7.
In my network, it's Windows that runs 24/7 - not Linux.
Linux runs about 20% of the time on my network.
So while Linux is always important (it's the portal to iOS for example),
Linux is only used when it's needed.
> meaning to read up on nextcloud as a replacement, but it's not the
> highest priority right now.
Philosophically, it seems OwnCloud is a "bad choice" for now, except for
legacy setups, based on the sour business issues, so it would be NextCloud
for anyone starting fresh (as I recall the conversation).
Even so, it's my understanding only a Windows hero could get it to work.
Maybe that's not the case - but that's my understanding.
Anyone who disagrees could easily post a step by step tutorial for setting
it up on Windows and I'd be glad to test it out - but I doubt anyone will
write that tutorial. I'ver personally written extremely many tutorials, so
I know how difficult step-by-step tutorials are to write.
> SMB / CIFS / samba is doable on a linux-based server as well.
Again, we have to mention "clients" or "servers", although I agree that
smbclients and samba servers are extremely robust on Linux.
So I'm not in the least worried - as I used to network the old Macs of the
90's era using columbia appletalk (caps) and the old SunOS machines (maybe
it was Solaris by then) with Windows (probably Win95 or Win2K).
Samba servers and smbclient clients are robust on Linux, so that's never
going to be the problem. Linux is easy. It's just not running full time on
most networks - so that's the only reason that Linux isn't the central
server for this home-network situation.
That's too bad that Linux doesn't run full time as a full-time Linux server
would solve most of the networking problems, given how robust Linux is
compared to the other platforms.
> to behave better when dealing with cross-platform setups; at least in my
> experience.
I agree with you that Linux behaves best cross platform as both server and
client.
The problem is simply that there is no dedicated Linux server 24/7 on most
home networks, including mine.
Some day I'll set up a $35 raspberri Pi as a dedicated 24/7 Linux server.
> Granted, the last time I _needed_ a samba share was years ago; Windows
> mya have gotten less sucky since 8/8.1.
Windows actually sucks at SMB (IMHO) due to the inability to change ports.
Other than that, SMB is the "native" solution for Windows.
SMB works just fine on Linux.
It's Android that has the problem with the ports not being the same as the
ports for Windows. As I recall (Frank Slootweg knows this better than I do)
o Android (non root) won't allow you to use ports below 1024
o Windows won't allow you to use the ports above 1024
So it's a catch 22.
I don't know how the SyncMe Wireless and AndSMB clients are supposed to
work non root.
Maybe someone on this newsgroup knows more than I do about this, because I
don't know ANYTHING about this type of networking, and, as proof, it's not
working for me to connect from Android to Windows.
Windows to Windows works fine, so we know the Windows setup is fine.
> I doubt he's running a "server" application on his phone.
I agree with you.
I _think_ the server should be the Windows box because it's 24/7 on the
network.
Just in case, though, we could easily run a server on Android.
In fact, running a WebDAV or FTP server on Android is trivial.
If folks want to try, here are the free software tools I'd recommend:
o Free WebDAV Servers on Android
<
https://play.google.com/store/apps/details?id=com.zq.webdav.app_free>
<
https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver>
o Free FTP Servers on Android
<
https://f-droid.org/en/packages/be.ppareit.swiftp_free/>
<
https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver>
The main problem with putting the MASTER passwd.kdbx file on Android
using a WebDAV or FTP server is simply that the Android device also
isn't on the network 24/7.
The only device on "most" home networks (at least on mine) that is on
24/7 is the router itself (which has a USB slot) and the Windows machines.
(As an aside, I should figure out how to use that empty USB port in the
back of the SOHO router - maybe it can host the Master kdbx file?)