SCST dev_vdisk errors

Recently, we received reports of SCST-related error messages from one of our SAN servers:
kernel: [1082754.895993] [4821]: dev_vdisk: ***ERROR***: write() returned -28 from 4096

A quick analysis showed that these errors started on a working day right after holiday season, but during the evening hours (so no-one was actively working on-site). From then on, we saw roughly 10 to 30 similar messages per incident, with these incidents occurring 45 to 90 minutes apart. What caught our eye was the fact that these incident were always on a quarter-of-an-hour mark. Continue reading

Posted in Linux | Leave a comment

Installing openSUSE Leap 42.1 on bcache root FS

Now that openSUSE Leap has been around for some time, I wanted to give it a try on one of our test SAN/NAS servers. One of the most basic elements of these SAN/NAS servers is using bcache to employ transparent block-level caching to SSDs, without the need for specialized RAID adapters. This allows for less expensive HDDs and/or more clients using these machines.

The current servers are running openSUSE 13.1, and using bcache right from the start (i.e. to put the root file system on a bcache device) was not for the faint of heart. So how have things evolved with Leap 42.1? Continue reading

Posted in howto, Linux, OpenSUSE, SLES (SUSE Linux Enterprise Server), SUSE | Leave a comment

Do you trust LinkedIn to handle your data correctly?

Recently, I decided to join LinkedIn, to complement my years-long appearance on a different business platform. Things do feel different, which was expected, and it took some getting used to. I added some info to my profile, set up a few links to business partners, and let it rest for a few days.

Then, notification emails started to appear in my email inbox, i.e. announcing new contacts for one of my connected business partners. As I am an adult netizen, these emails are presented to me with their plain text content, rather than the HTML version. And looking through that plain text content, I noticed something strange:

From: LinkedIn Updates <messages-noreply@linkedin.com>
 Subject: <my business partner> has added contacts you might know
To: j mozdzen
[...]
 
 <my business partner> has 4 new contacts:
   John Doe
   some job
   Show profile of John Doe: <some url>
 
   Firstname Lastname2
   some job
   Show profile of John Doe: <some url>
 
   Firstname Lastname3
   some job
   Show profile of John Doe: <some url>
 
   Firstname Lastname4
   some job
   Show profile of John Doe: <some url>

So the email generator this time has a tiny bug, inserting the name of the first new contact preceding the links to the profiles of all contacts in this list. This is nothing spectacular and wouldn’t justify a blog article on its own.

What does, is the reaction of the LinkedIn support team. These kind of errors are the pre-steps to data leaks, and should be looked into accordingly by the support team. I had forwarded them a description of the issue, first-level support handed it to second-level support, and the latter simply didn’t want to spoil their day by doing work: All I got in response was that this would have to be reported by the owner of the sending account.

No-one, even after me asking back, did even a quick check to see if the problem is reproducible (which would have been an easy task, using three test accounts I’m sure are available to the support staff). But LinkedIn obviously has not interest in fixing obvious problems, but rather prefers to close them without even looking into the details.

And that’s where the question from this article’s title came from, and it’s not even about privacy: If they don’t care to look into even this obvious error, I wouldn’t trust them to react if I reported a case of serious mis-represented data, maybe mangling my list of skills or alike.

After this experience, my answer to it is clear: No, I don’t trust them to handle my data correctly.

Posted in Linux | Leave a comment