Duplicati

On 6/27/19 7:17 PM, VanguardLH wrote:
Frank Slootweg wrote:

For Gmail, you can get around this problem by using an App Password
instead of OAuth2.

I just found:

https://support.google.com/mail/answer/185833?hl=en

If T thinks OAUTH2 improves on security and privacy, that is NOT what it
does. He should watch the Vimeo video by Hammer where he's disgusted
with what became of his offspring.


Vanguard,

You are not following. I made no evaluation as to how
good OAuth2 is or is not. This is about the user
turning "less secure apps" back off. I was looking
for a backup open source backup programs that supported
AOuth2 so that I did not have to hassle with the user
disabling their damned eMail reports.

-T

p.s I have never personally looked into whether
OAuth2 is a good thing or not. It superficially
think that SSL/TLS should be fine, but I really
don't have an opinion on it.

On 6/27/19 7:15 PM, VanguardLH wrote:
So, let's see what I can do with non-OSS software

You wouldn't happen to have one of these reports for
Open Source Software?

T wrote:
On 6/28/19 6:29 AM, Frank Slootweg wrote:
T wrote:
On 6/27/19 1:14 PM, Frank Slootweg wrote:
T wrote:
[...]
"OAuth2 (gmail, yahoo)".

Yes, you can disable it on gMail and Yahoo, but the ass holes
keep sending out robo eMail telling the user to "Turn off
untrusted apps" and it "scares" the users, so they eventually
turn it off, despite what I say, and it breaks those clients
not using AOuth2.

For Gmail, you can get around this problem by using an App Password
instead of OAuth2.

For how to do this, see Ralph Fox' 09SEP2018 post "Google screwed up
my Gmail acct in Thunderbird" in alt.windows7.general:


or
Message-ID:
or
http://al.howardknight.net/msgid.cgi?STYPE=msgid&A=0&MSGI=%3C0ud8pd5m6ler41kl %3E
or
Get a *real* newsreader! :-)

Ralph's post talks about POP (which I needed), but it's also
applicable to SMTP (which you need).

FWIW, I've no such problems with Yahoo, but I only POP from them, i.e.
no SMTP.

N.B. Thanks Ralph!

Yes exactly, until the customer gets one too many turn off
less secure apps and then it comes down around your ears.
They lose their tape reports, but WHEN DO THEY EVER CHECK
THEM ANYWAY!

False. There won't be any "turn off less secure apps" messages,
because Gmail/Google considers App Passwords as secure as OAuth2.

You sure about that? Hmmmmmm .... Maybe they are getting
this on their eMail reader because another "less sure app" is
accessing their SMTP server. It is best not to make
blanket statements, like "WRONG" or "False". It is rude
and does not make you any friends. This is not a fight
between us. Don't turn it into one.

Yes, I'm sure about that and so is VanguardLH and so is Ralph, ...

About "rude", "friends", "fight", etc.. It's rude to dismiss and doubt
advice without even reading it, let alone trying it. So it's best to
look in the mirror before casting stones.

Ralph's post clearly says:

RF An app password gives you two advantages
RF 1. You can turn off "allow less secure apps";

So don't reject advice before even reading it, let alone trying it.

And you somehow thought I was not turning "less secure apps on"?
That is part of the routine. Then I have to go back and do
it several more times as the user turns it back off. Maybe
you are not reading or not following?

You're the one not reading or not following! Use App Passwords for
Gmail and you can turn off "allow less secure apps". If you turn it on,
then you might get e-mailed complaints again (but only from *other*
(than the e-mail clients) apps). So why the heck would you turn it on if
there is no need!?

Bottom line: Your "routine" needs to change, because you now have a
*solution* (App Passwords), instead of a *hack* ("allow less secure
apps").

This is about using OAuth2 so as not to have to hassle with
the user turn the stinker back off.

And App Passwords accomplish the exact same thing.

On 6/27/19 7:31 PM, VanguardLH wrote:
You sure these customers that you paint as morons are falling for phish
e-mails?

No it is the real deal. And when they log in with web mail, they
get the same stuff.

And they are not morons, they just have different priorities
than I think they should have. So not morons, but "frustrating"
at times

One customer that I fixed his backup, when I asked him why he did
not tell me when his reports said something was wrong, his response
was "I don't have time for that kinds of s***!" So different
priorities, just so long as he/they graciously accepts when he need
his backup and it is not there.

On 6/28/19 12:21 PM, Frank Slootweg wrote:
T wrote:
On 6/28/19 6:29 AM, Frank Slootweg wrote:
T wrote:
On 6/27/19 1:14 PM, Frank Slootweg wrote:
T wrote:
[...]
"OAuth2 (gmail, yahoo)".

Yes, you can disable it on gMail and Yahoo, but the ass holes
keep sending out robo eMail telling the user to "Turn off
untrusted apps" and it "scares" the users, so they eventually
turn it off, despite what I say, and it breaks those clients
not using AOuth2.

For Gmail, you can get around this problem by using an App Password
instead of OAuth2.

For how to do this, see Ralph Fox' 09SEP2018 post "Google screwed up
my Gmail acct in Thunderbird" in alt.windows7.general:


or
Message-ID:
or
http://al.howardknight.net/msgid.cgi?STYPE=msgid&A=0&MSGI=%3C0ud8pd5m6ler41kl %3E
or
Get a *real* newsreader! :-)

Ralph's post talks about POP (which I needed), but it's also
applicable to SMTP (which you need).

FWIW, I've no such problems with Yahoo, but I only POP from them, i.e.
no SMTP.

N.B. Thanks Ralph!

Yes exactly, until the customer gets one too many turn off
less secure apps and then it comes down around your ears.
They lose their tape reports, but WHEN DO THEY EVER CHECK
THEM ANYWAY!

False. There won't be any "turn off less secure apps" messages,
because Gmail/Google considers App Passwords as secure as OAuth2.

You sure about that? Hmmmmmm .... Maybe they are getting
this on their eMail reader because another "less sure app" is
accessing their SMTP server. It is best not to make
blanket statements, like "WRONG" or "False". It is rude
and does not make you any friends. This is not a fight
between us. Don't turn it into one.

Yes, I'm sure about that and so is VanguardLH and so is Ralph, ...

About "rude", "friends", "fight", etc.. It's rude to dismiss and doubt
advice without even reading it, let alone trying it. So it's best to
look in the mirror before casting stones.

Ralph's post clearly says:

RF An app password gives you two advantages
RF 1. You can turn off "allow less secure apps";

So don't reject advice before even reading it, let alone trying it.

And you somehow thought I was not turning "less secure apps on"?
That is part of the routine. Then I have to go back and do
it several more times as the user turns it back off. Maybe
you are not reading or not following?

You're the one not reading or not following! Use App Passwords for
Gmail and you can turn off "allow less secure apps". If you turn it on,
then you might get e-mailed complaints again (but only from *other*
(than the e-mail clients) apps). So why the heck would you turn it on if
there is no need!?

Bottom line: Your "routine" needs to change, because you now have a
*solution* (App Passwords), instead of a *hack* ("allow less secure
apps").

This is about using OAuth2 so as not to have to hassle with
the user turn the stinker back off.

And App Passwords accomplish the exact same thing.


Hi Frank,

Thank you for helping me update my kill file. I don't
have time for people who pick fights.

-T

T wrote:
On 6/28/19 6:14 AM, Frank Slootweg wrote:
T wrote:
On 6/27/19 1:14 PM, Frank Slootweg wrote:

If I were you, I would just continue to use Cobian Backup till it
breaks. (I sure will do so for our systems.)

That is what I am doing. The OAuth2 problem is starting
to become a pain in the ass.

As I described in my other response, there is no such thing as "The
OAuth2 problem", at least not for Gmail. I will respond to your response
in that subthread. See also VanguardLH's response on the same issue.

As to your requirements:

1) open source

Should be irrelevant. Most other software your customer and you use
isn't open source either. (N.B. I've been doing Unix/UNIX/unix since
nearly four decades, but I'm no open source zealot (nor a free software
one).)

It is not. Open Source keeps old version around for you
if you need them. Paid softwaree only keep a certain amount
around and want you to upgrade. So you pay them and upgrade,
and guess what, your old version is too old and you lost
everything. But, wait for a fee, you can send it to them
and they will recover it for you. It is a scam.

Commercial backups are a lock in to use their services.
Not funny when disaster strikes.

Open source also typically is driven by need, not by what
locks you into paying for services.

The opposite of open source is closed source, not paid software. That
closed source *may* be paid software, but it can also be freeware (such
as Cobian Backup). (And then there is the case of paid open source
software.)

In any case, the whole point is moot, because 1) you are free to keep
using old copies and 2) your *own* requirement is

2) have plain backups able to be read by any reader

so there *cannot* be a case of "you lost everything".

3) eMail reports OAuth2 would be a plus

Gmail alternative solution described in my other response.

True. But you are not walking in my shoes. It does not
matter what I tell the custom, when they get those
constant eMailing to turn off less secure apps, the
eventually do.

False. See my response in the other subthread.

Now, that means they don't get their eMail reports. BUT
SINCE WHEN DO THEY READ THEM ANYWAY. I have to Cc myself
on everything and check them for them.

2) and 4) are of course covered by Cobian Backup.

BTW, is the backup device always on/connected? If so, then why don't
you just use File History and be done with it? It wouldn't have 3) and
4), but there would be no need for those.

You are thinking of a fully functioning machine. Think hard drive
as paper weight.

Just answer the question please. I assume you have the common sense to
backup to *another* disk (than the main/normal/whatever disk). Even if
that backup disk is in the same computer (not so smart), it won't be a
"paper weight" if the computer or/and main disk goes down.

Frank,

I am not sure here we stand on this. I do believe this
was answered on other conversations. And yes, I am not stupid enough
not to use separate media.

As you apparently can't be bothered to address the other points, nor
answer the question(s), there's no point to continue.

T wrote:

VanguardLH wrote:

So, let's see what I can do with non-OSS software

You wouldn't happen to have one of these reports for
Open Source Software?

Other than a Google search and review each myself that you could do?

T wrote:

I can't control what platform they use to read their eMail. Often
times I set them up to whatever platform they want, then find them
months later on some tother platform.

It is their choice as to who they use for e-mail service. It is also
your choice, when you setup Duplicati, as to which e-mail service it
uses. Those don't have to be the same e-mail service. Using Duplicati
to send reports via Gmail (with the insecure option disabled) or through
some other e-mail provider is independent of the users getting messages
from whomever they choose to be their e-mail provider. Even without
using Duplicati or never having the backup program send e-mailed
reports, those same users using Gmail are STILL going to get those bogus
messages about using an insecure client with Gmail.

You know, it just occurred to me that I should create a new gMail
account to send out backup reports. If the customer does not
have access to the account, or easy access the can play with,
they won't see the less secure apps s. And, since the app won't
physically move about ...

You NOT WANT USERS TO BE SHARING THE SAME E_MAIL ACCOUNT. With multiple
users logging into the same e-mail account, one of them will eventually
**** up that account. They will delete e-mails that are not yet viewed
by the other users. They can change settings, setup a vacation
responder, change filters, alter the login credentials, and so on. The
users should have NO ACCESS to whatever e-mail service that Duplicati is
using (other than some admin assigned to the e-mail management task, but
who still uses his own e-mail account at which to recieve the reports).

The e-mail account that Duplicati uses is considers part of that
software configuration. Only sysadmins should be touching the Duplicati
config, and the same for the Duplicati-assigned e-mail account. Just
because the e-mail provider is outside of the Duplicati software doesn't
mean the e-mail account is not part of Duplicati's config realm.

T wrote:

On 6/27/19 7:31 PM, VanguardLH wrote:
You sure these customers that you paint as morons are falling for phish
e-mails?

No it is the real deal. And when they log in with web mail, they
get the same stuff.

And they are not morons, they just have different priorities
than I think they should have. So not morons, but "frustrating"
at times

One customer that I fixed his backup, when I asked him why he did
not tell me when his reports said something was wrong, his response
was "I don't have time for that kinds of s***!" So different
priorities, just so long as he/they graciously accepts when he need
his backup and it is not there.

If they are hiring you to be their sysadmin or tech support, why aren't
you having the backup software send or BCC the reports to you?

Andy Burns wrote:

VanguardLH wrote:

He should watch the Vimeo video by Hammer where he's disgusted with
what became of his offspring.

Linky?

In my first reply, I cited the URL (at Google Groups and in Howard's
archive) for an old post of mine where I mentioned the URL to the Vimeo
video of Eran Hammer's speech. Below is the Vimeo URL outside that old
post:

https://vimeo.com/52882780

You'll see E. Hammer's name on the RFC for OATH 1.0 *Protocol* at:

https://tools.ietf.org/html/rfc5849

I think he stepped away when the IETF submission process was too
political and too stupid for him to bother, so he isn't listed in the
RFC for OAUTH 2.0 *Framework* (but is listed in the References section)
at:

https://tools.ietf.org/html/rfc6749

searching vimeo for "oauth2 hammer" turns up no needles, searching for
just "oauth2" or just "hammer" turns up too many haystacks.

Just search on "hammer oauth" (no version number of OAUTH since worked
on both OAUTH 1.0 and 2.0).

T wrote:

On 6/27/19 7:17 PM, VanguardLH wrote:
Frank Slootweg wrote:

For Gmail, you can get around this problem by using an App Password
instead of OAuth2.

I just found:

https://support.google.com/mail/answer/185833?hl=en

If T thinks OAUTH2 improves on security and privacy, that is NOT what it
does. He should watch the Vimeo video by Hammer where he's disgusted
with what became of his offspring.


Vanguard,

You are not following. I made no evaluation as to how
good OAuth2 is or is not. This is about the user
turning "less secure apps" back off. I was looking
for a backup open source backup programs that supported
AOuth2 so that I did not have to hassle with the user
disabling their damned eMail reports.

-T

p.s I have never personally looked into whether
OAuth2 is a good thing or not. It superficially
think that SSL/TLS should be fine, but I really
don't have an opinion on it.

I have another reply to you where you make it sound like the users are
sharing the same Gmail account as Duplicati would/does use to send its
reports. Only the same admin of Duplicati should ever touch whatever
e-mail account is used by the backup program to send its report. That
e-mail account is part of the configuration of the backup program, not
for end-user use.

Because the users are using Gmail (which should NOT be the same Gmail
account, if Gmail at all, that Duplicati uses), any messages from Google
about the security of their clients, security alerts regarding app
access, and so on are ONLY related to each users decision to use Gmail,
not anything to do with the operation and configuration of Duplicati.
The Gmail account used by Duplicati might send such messages to
Duplicati's e-mail account, but Duplicati won't care (it likely does
nothing with e-mails /received/ to the e-mail account from which it
/sends/ its e-mailed reports).

On 6/28/19 8:09 PM, VanguardLH wrote:
T wrote:

VanguardLH wrote:

So, let's see what I can do with non-OSS software

You wouldn't happen to have one of these reports for
Open Source Software?

Other than a Google search and review each myself that you could do?


Already did. I even found alternatives to Cobian.
That is were I came up with Duplicati

I was just wondering if you had done any research
that would help. Your knowledge is quite extensive.

On 6/28/19 8:18 PM, VanguardLH wrote:
You NOT WANT USERS TO BE SHARING THE SAME E_MAIL ACCOUNT

"user" singular, not "users" plural. The user's (possessive,
not plural) typically have multiple devices reading the
same account.

On 6/28/19 8:19 PM, VanguardLH wrote:
If they are hiring you to be their sysadmin or tech support, why aren't
you having the backup software send or BCC the reports to you?

Both and I do. I get up to 400 per week. It
is their jobs to read the damn things. I only
go behind them as a courtesy. I call them
when I don't see reports coming through. But
I an be two weeks behind them.

On 6/28/19 8:34 PM, VanguardLH wrote:
T wrote:

On 6/27/19 7:17 PM, VanguardLH wrote:
Frank Slootweg wrote:

For Gmail, you can get around this problem by using an App Password
instead of OAuth2.

I just found:

https://support.google.com/mail/answer/185833?hl=en

If T thinks OAUTH2 improves on security and privacy, that is NOT what it
does. He should watch the Vimeo video by Hammer where he's disgusted
with what became of his offspring.


Vanguard,

You are not following. I made no evaluation as to how
good OAuth2 is or is not. This is about the user
turning "less secure apps" back off. I was looking
for a backup open source backup programs that supported
AOuth2 so that I did not have to hassle with the user
disabling their damned eMail reports.

-T

p.s I have never personally looked into whether
OAuth2 is a good thing or not. It superficially
think that SSL/TLS should be fine, but I really
don't have an opinion on it.

I have another reply to you where you make it sound like the users are
sharing the same Gmail account as Duplicati would/does use to send its
reports. Only the same admin of Duplicati should ever touch whatever
e-mail account is used by the backup program to send its report. That
e-mail account is part of the configuration of the backup program, not
for end-user use.

Because the users are using Gmail (which should NOT be the same Gmail
account, if Gmail at all, that Duplicati uses), any messages from Google
about the security of their clients, security alerts regarding app
access, and so on are ONLY related to each users decision to use Gmail,
not anything to do with the operation and configuration of Duplicati.
The Gmail account used by Duplicati might send such messages to
Duplicati's e-mail account, but Duplicati won't care (it likely does
nothing with e-mails /received/ to the e-mail account from which it
/sends/ its e-mailed reports).


I am thinking along the same lines as you, that I should not
use the same account to send out reports. I don't do this
on servers already, so why not on their workstation as
well. It would get around the OAuth2 problem