The FoxIt Linux Fiasco —
Last night when I was off-site furiously doing a major upgrade on a client’s server I checked my email. I quickly glanced at the RKHUNTER logs sent to me by a script I crafted up a long time ago. They were for my primary Linux system at home. My heart skipped a couple of beats when I saw this:
Warning: Suspicious file types found in /dev:
/dev/shm/sem.Schedule: data
/dev/shm/sem.Deliver: data
/dev/shm/sem.CLOUD: data
Uhhh, what? CLOUD?? Schedule? Deliver? This doesn’t look good.
With my mind in a few different places at once already with the tasks I was involved in, I started mildly freaking out. I couldn’t deal with this as Windows Server 2016 was being a little bitch, taking hours to “update” (READ: puke all over itself and pass out with no indication to me). And for some reason I couldn’t connect to my home VPN to investigate. Uuuuuugh.
For a split second I wondered if it was the FoxIt Reader I installed the other day, but thought to myself, nah – was it even open at the time? Does a PDF reader for Linux need these kinds of functions? I installed FoxIt to get away from Evince as I really, really hate the GTK3 app style, and IMHO Evince has some peculiarities that really got to me over the years…and I’ll be damned if I taint my system with anything created by Adobe (Flash is dead! Long live HTML5!)
Come to find out it actually *was* FoxIt. I came home and found an instance open and closed it – viola, /dev/shm was clean now.I’m going to have to look closer at FoxIt’s license and overall functionality (rather the ability to disable some of it) if it is in fact doing “cloud” things without me specifically telling me to…even if it’s simply loading the function. That’s not how Linux apps should work, IMHO.
Categorised as: Blogs | Technical
How to bitch-slap WS2016:
1. Manually download SSU (servicing stack update) *first* from M$ Update Catalog
2. Install downloaded update file
3. Reboot
4. Install the LCU (latest cumulative update) any old way
5. Profit!
Thanks!! So the SSU was updated, though through the automatic update process. This was the only update that actually succeeded when doing all updates. Do you know why you’d have to manually download it? More importantly, should we really have to deal with this on a “server OS”?
As I understand it, the problem is that the SSU has to be in place and the new “Windows Update” has to be active in RAM or … well … or else. The manual download and install and reboot is to make for *damn* sure that it’s the only thing getting installed before the new Windows Update programs are in RAM. In my paranoia, I’ve even tried to disable the Windows Update service while I’m doing this, but unfortunately you can’t install a .MSU without the service running. Stopping it seems to be your best bet.
No, we shouldn’t have to deal with this obviously and there’s been lots of noise about it. Supposedly it will be better in server 2019, but I think the whole “the OS will delete your files” fiasco has really spooked people and made this thing look like a minor glitch. Just another example of software getting worse over time instead of better. Gotta love the *AAS model, right? Or was it *ASS? I always get them mixed up…