Feeds:
Posts
Comments

Archive for the ‘Cloud’ Category

My setup has been the same since quite a few years now: I have a Keepass file on Dropbox, and I use several different applications and apps on multiple devices to access and update that file. Which applications, you ask?

On my Macs as well as on my Xubuntu machines I will use Keeweb. Despite its name, it gives you a desktop application that natively accesses (and syncs) files on Dropbox. This is the application I go to for when I want or need to reorganise the Keepass file, e.g. to rearrange groups or import lots of account data.

I would use Keeweb on a Windows PC as well – if I had one. At work, we have no free choice of which application to use to store passwords, but luckily we do have the “official” Keepass Password Safe at our disposal.

On Android my favourite Keepass app is called Keepass2Android. I will admit that I made that choice a few years ago, and haven’t checked on its competitors recently (are there competitors of note, by the way?). But it does what I need it to do; it accepts Dropbox as cloud storage and it will even merge changes from the local version and the Dropbox version when it detects differences between the two during the synchronisation process. That last one is a killer feature, and it hasn’t failed me a single time in the years I have been using it.

On iOS the situation is a little more complicated – at least, that how it feels to me. I wrote earlier about KeePassium, and that is still my app of choice. I like the interface, and it does all I need when I look for account info (you can store more than just passwords there!).

But in order to sync my central file on Dropbox, on iOS the app has to go through the “Files” app from Apple. Files-the-app is capable of showing files of all kinds on the iOS device, as well as the files on several cloud file systems, like Dropbox. What is less clear to me, however, is how quickly “Files” notices changes on Dropbox and picks up the latest version of my central KeePass file. I also have had trouble getting the latest version of my file (as changed on Android, for example) onto my iPhone. Although I must admit that the last few weeks fared better: I haven’t noticed anymore missing syncs lately. What I can’t say is whether the issue was/is with Files rather than KeePassium or even my internet connection…

Anyway, when it comes to passwords I want to be sure that I’m not missing any information – or worse: I don’t want to overwrite my updated central file with an older version on iPhone! That’s why I currently always check the “last updated on” date of my Dropbox file in Files before opening the file again. Of course my Dropbox account is protected with a password, but I don’t think that is what Andrei Popleteev means when he’s writing about “How to sync KeePassium with Dropbox“.

Manually checking the file date on iOS is not an ideal situation, I know, but to me that check is a small price to pay for the greater good of having my account data available on all the platforms I use! And for me, KeePassium is still the way to go on iOS.

Read Full Post »

As mentioned earlier, my ‘Grive2’ solution stopped working around November 25, and that is still true today. I have copied the daily updates by hand for a few days, but that is not a permanent solution.

That left me no choice: I needed to find another tool to replace ‘Grive2’. Luckily I had already been experimenting with ‘Jdrivesync‘ somewhere in 2018. The scripts I created at the time should still have worked today (I had kept everything in place), but a first attempt failed with an unclear exception message about OAuth.

Just to be thorough I checked the app access settings on my Google account. I found no sign of ‘Grive2’, just mention of an ‘Ubuntu’ app. So I thought: let’s get rid of that and try again. But that didn’t improve the situation. Strange, because in theory ‘Jdrivesync’ was now supposed to ask for a new authorisation key, and it did not do so.

Looking in my home directory on the Xubuntu I quickly found the culprit: the file .jdrivesync does contain the accessToken and refreshToken required by Google/OAuth. Deleting the file finally did what I wanted: Jdrivesync requested a new authorisation code and ran as it is supposed to do. Nice, although I should point out that Google again complained about not having verified Jdrivesync and did I really want to continue whit that app? Of course I do!

Now I just have to adapt crontab ;-)

PS. I will also keep an eye on the ‘google-drive-ocamlfuse‘ project. That would allow me to mount the Google Drive file system on the Xubuntu machine, giving me an opportunity to learn how to use rsync… But that’s for another time!

Read Full Post »

I have been using Grive2 for a couple of years, to help me get the numbers from our photovoltaic panels into Google Drive storage. That has been going very well… until today.

The new or updated files from my panels did not show up today, although they had been created correctly on the EeePC. When I tried the Grive2 synchronisation by hand, the tool reported a 401 error: access not allowed. I suspected an issue with the Apps authorisation for the Google account concerned, so I deleted the existing ‘grive’ App and launched a new registration request. Alas, to no avail; this is what Google had to say:

Why, oh why, Google?

All I can say is: come on, Google! This has been working fine for a couple of years – why cut it off now? If you really had to cut off access, why not alert the its users first? And what is “temporarily”: a day? a week? forever?

I will copy the files by hand for a few days, but that solution won’t last long. After all, we automate processes so we don’t have to remember doing them, the more so when the process is tedious. Copying files by hand is tedious, and error-prone too…

Read Full Post »

Reconnected To LinkedIn…

I tried to reconnect this WordPress blog to LinkedIn tonight, like I have been doing several evenings since my post from a week ago. I saw the error message mentioned earlier multiple times during my trials. This time it worked, just as it should. Let’s hope the situation holds out from now on!

Read Full Post »

The post on this blog have been “publicized” on Twitter and LinkedIn since many years. Since about three weeks or so, WordPress keeps saying that there is an issue with the connection to LinkedIn. What should be a simple matter of a few clicks and typing a password is turning into something unpleasant. The moment I ask LinkedIn to authorise WordPress, I usually get this message: “Failed to load your request token while connecting to LinkedIn“. LinkedIn seems to accept the request, but WordPress is unable to retrieve the required key and tells me to try again… and again… and again.

I have lived through that scenario on multiple days, so yesterday I hoped to outsmart both applications: I deleted the existing authorisation in LinkedIn, disconnected WordPress from LinkedIn, and then tried to connect WordPress to LinkedIn as if it were the first time I did so. Guess what?

Error message: “The LinkedIn connection could not be made because no account was selected.

A new error message appeared: “The LinkedIn connection could not be made because no account was selected.” I guess I’ll have to live a few days/weeks without postings on LinkedIn.

Note: I’m doing all my WordPress stuff in a browser on the Mac…

The big picture is a bit disappointing, of course. Here we have to giants on the Web, whose services are explicitly built to be connectable – and then that connection fails. It fails not once, but several times over a period of weeks. It seems as if no one at either company is checking the log files of those applications (it’s hard to imagine that I’m the only one encountering this issue). Perhaps these companies are too big to notice (or worse: care about) such failures?

Read Full Post »

This is the wrong time of the year to encounter this problem! I have all my contacts in the Google Mail and Contacts application (GMail) , and when I try to access them in a browser this is what I get to see:

What? No contacts?

What? No contacts?

I have tried it in Safari and Google Chrome on Mac, and I tried it in Chromium on Lubuntu – all gave me this same white screen. Switching to the network console in Chrome tells me there is a 404 response somewhere in the application…

Am I just the only one that won’t be able to send out my wishes for the new year? And if so, what is provoking this behaviour of the application?

 

Update (4 hours later): you can use this link www.google.com/contacts/u/0/?cplus=1#contacts to access your contacts using the “old style application”…

Read Full Post »