Category Archives: *nix

quarantined file issues in Mavericks OSX

0 comments *nix, command line, css, Hosting, linux

Ok, so ever since I upgraded to Mavericks from Mountain Lion, I’ve had crazy issues dealing with font files that I’ve downloaded. At first, I thought it might be some sort of font issue with Mavericks, but it turns out it’s a quarantine issue with downloaded files.

For a bit now, OSX quarantines files that are downloaded. It’s a nice security feature, but dang, it’s really messing me up :/ I’m not sure yet why my box is behaving this way. I’m sure there’d be massive outcry if this were a rampant issue.

When a file is downloaded, some extra meta is added to it. You can tell from the command line as the permissions look something like this when you list all aka ‘ls -la’ …

drwxr-xr-x@

The work around I’ve pieced together that I have to do each time I download a zip file is to unpack it, then run xattr on it to remove the quarantine flag. Here’s an example of a style.css file that I ran this on to allow scripts on my box to see the file.


xattr -d -r com.apple.quarantine style.css

or

xattr -dr com.apple.quarantine style.css

What should happen is when I click to unzip the zip file, I should get a GUI alert that asks me if I really want to open this file from the internet. Sadly, it’s not happening on my box.

Anyway, hope this helps the random person out there searching for a possible solution.

Update: 4/16/14

It would be helpful to let you know how to actually find the bit of data to remove. Above you see com.app.quarantine. That’s the metadata you need to remove. To find it simply type…


xattr somefilename

That’ll output a string which you’d put in place of ‘com.apple.quarantine’ as seen above.

ZIP issues on WordPress plugin updates

0 comments *nix, command line, Hosting, linux, wordpress tips

So, today I was helping out a colleague with some WordPress installations. When adding plugins or updating ones that were there, I encountered this well commented but not resolved error…

PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

Now, there’s a bunch of folks talking about this issue, with solutions ranging from not enough disk space, to permissions issues.

This issue occurred for me on a mediatemple grid server. I was not able to upload or upgrade any WordPress plugins on new or older versions of WordPress. This occurred in WordPress installs that did not have this problem before. Further, if I was on the server via the commandline, I could scp the zip files up and unzip them. The issue was only within the WordPress GUI. So, my guess is whatever process WordPress uses to unzip plugins is what’s causing the problem.

I’m pretty sure that the issue came about when the ZIP package was globally updated on the server recently. Since the php.ini file for the account was customized in some way, and it didn’t reference the correct zip extension, unpacking zip files via the WordPress GUI failed.

When I added ‘extension = zip.so’ to the php.ini file, this resolved the issue. I don’t know that this is the perfect solution for anyone else, but just another data point for folks looking for info.

Hope this helps someone out there 🙂

when ssh is not available

0 comments *nix, command line, Hosting, linux, server, unix

As a web developer, I often encounter clients who have a hosting package that is limited, or ‘secured’ by the hosting provider.  That means I sometimes am forced to use the dreaded FTP for file transfers rather than SCP.

This is ok when it’s just a few files here or there.  In fact, using the GUI can sometimes be convenient.  However, if I’m doing large scale development, I’d rather copy the site over to my development server rather than work locally and fill up my hard drive.

If the client’s hosting provider does not allow SSH access, then you can use FTP from the commandline 🙂

ftp ftp.example.com will get you there.  Then depending upon your flavor of linux, you can use MGET to pull files.  Sometimes you are even offered the awesomeness of RECURSIVE MGET *.

When you are not afforded that goodness, I’ve discovered that WGET does the trick even better 🙂

wget -r “ftp://user:[email protected]/somedirectory”

That’ll recursively get it all for you 🙂  Better yet…mirror

wget -m “ftp://user:[email protected]/somedirectory”

That initiates recursive and gives you infinite depths on directories…and…gives you the same timestamps as exists on the remote server.

Nice stuff.

 

The Benefits of webmail and another pitch for gmail or google apps

0 comments *nix, command line, email, IT systems

Today I discovered a great reason to utilize webmail rather than some local client like Outlook or Thunderbird.

You see, I recently switch all my emails over to Google Apps, and have been using Mailplane to access my emails.  Mailplane is pretty much a glorified desktop client that is really just an interface to gmail.  Essentially, when I turn on Mailplane, it’s as if I’m turning on Safari and logging into gmail.  All emails and attached files are sitting on Googles servers, and not on my computer.

When I switched over to Google Apps and Mailplane, I thought that was cool and all…until today.  Today, I realized how INCREDIBLY cool it is.

Today, I was digging around on my hard drive, wondering why the heck it was so full and trying to recapture some of that space.  I downloaded a nifty little application, Disk Inventory X, which shows you, visually, what’s actually on your hard drive.  Sounds silly, but when you are hunting around for what’s eating up your hard drive, and you don’t feel like hitting the command line and DFing everything, this little utility comes in handy.  Today it showed me some serious old file storage that did not need to be there.

As it happens, I was using Thunderbird as a mail client before.  It’s kept all my emails that were on google apps or gmail to the tune of 50G.  Seriously.  All that data is on Google’s servers AND my computer.  Now that I don’t use Thunderbird anymore, WHAM, 50G freed up!  Whoot!

Can you imagine what Outlook is doing to folks?

Another thing it showed me was how DropBox retains a copy of something if you unsynch it.  I’d unsynched about 8 gigs of data today, but it didn’t seem to be gone.  Then I found the Dropbox cache…8 Gigs.  WHAM, 8 Gigs freed up.

Sweet, now I’m about 60 Gigs lighter.  If only I could do that to my waist 😉