Day: November 6, 2003

MT Plugin Manager

looky

After tag-teaming stupid MT shacolby and I finally succeeded at trying to get this MT Plugin Manager to work.

I installed on our system:

by copying the
master list of all the plugins, renaming it to plugins.xml and placing
it in the plugins/ directory, then copying styles-pm.css to the mt-static directory, I at least got the thing to display- but now the “manual install” page still doesn’t work.

  • the individual files it finds start with a .//usr/local/apache rather than just “/”. Why? Does that matter?
  • the “action” field in the FORM (post) entity in the page is empty, which seems to suggest it wants the same CGI that generated the page, mt-pm.cgi

  • the same mode, __mode=manual_install, is specified as a key-value pair

  • the unknown plugin file (e.g. mt-amazon.pl) is also misnamed in the FORM: changed that too
  • Manually edited file and ran on client to get this to work… nothing yet
  • Within Manager.pm, “manualInstall” does most of the work, generating the page listing all the unknown files (potentially plugins) and farming out to “manualInstallFile” if information is coming in from a form
  • maybe the save process is just not working? PluginData.new() is being called… defined in MT::PluginData.pm (in lib, not extlib/MT/Plugins). Where is this data stored?
  • Looks like the manual registry is working, however the manual registry page doesn’t make previously-registered files go away
  • If the plugin in question is a simple series of files, (like perl files), then there is no problem, and the installation goes well

  • however, if there is unzipping involved, we get problems: compilation stops on things like

    Bareword “Z_OK” not allowed while “strict subs” in use at /usr/local/apache/cgi-bin/mt/extlib/Archive/Zip.pm line 1808

  • testing on ArchiveYear and IfArchive – both of which use .zip files to install
  • the files in the working blogs are owned by user www-data and group ftp– yet the .zip files brought into manager-cache are
    owned by user www-data and group www-data.
  • Even the successfully installed plugin, FilterCategories, is permissions 644. Will this run?
  • shac tried quoting all the return values in Zip.pm… this got rid of some errors. But that means the errors were there because the return types were not defined, which is probably in Compress::Zlib
  • damn, it’s looking like :
    1. There are two different Zlib.pm modules: Compress::Zlib and IO::Zlib
    2. we have two of each on our system- we already had them installed in our perl, in /usr/lib/perl5/site_perl/5.6.1,
      and now we have one in the MT installation
    3. the MT installation version may not define Z_OK ?
    4. I added a debug to print out @INC.. sure enough we are using the MT version first… should I update the MT libraries, or just mess with “use lib”?
      I’ll update the libraries.
  • uh oh- our Compress::Zlib and IO::Zlib modules in MT are identical. I think we screwed up the install.
  • yep that was it… deleted that one… now the main problem is permissions. At this point there are two ways to fix it that I can see:
    1. open the libraries to any user, or get shac to put every system user in the same group and do it that way. Acutally, the user owning the libraries right now is not the MT user for a reason; I wonder if we should change that or not, it seems like a security risk?
    2. Modify Manager.pm so it is smarter about file ownership and permissions. If I do that, I guess I should insert the fix in the bug tracking report to be a good MT citizen…

Mum- finally we are no one

looky
this CD is the coolest thing ever
it's putting me in a coma
I feel like I'm on drugs
I have to save the rest for later

Wow this thing is great- possibly greater than Sigur Ros.

Quiet Icelandic ambient / electronica that sounds like you are in a waking dream- I would let you listen to it, but that would mean letting you touch my copy, and I will slit your throat and violate your corpse before that happens.

B000066HH0

Speaking to the Future; Nuclear Waste

looky

The Long Now Foundation creates things that will last “forever”- clocks, libraries… the exercise is fascinating. The purpose statement on their site is great reading by itself; they also have a book, “The Clock of the Long Now: Time and Responsibility: The Ideas Behind the World’s Slowest Computer“

Their Clock of the Long Now is designed to tell accurate time for 25,000 years. How would that be possible? The issues involved are staggering. The clock is designed to withstand corrosion and can be re-set using the sun and no knowledge of written language or tools. The clock has been designed to withstand the fall of civilization; it can be fixed with bronze-age tools.

No less ambitious is the Rosetta Project (part of the Library project), a series of spherical artifacts intended to make the task of translating all our written languages easer for archaeologists 10,000 years into the future. Making historical artifacts for the future.

A real-life application of this same thought exercise: the WIPP, a giant underground repository for nuclear waste. It will be radioactive for the next 25,000 years. How do you warn future generations away from the site? They won’t speak English, they will not have computers, they may not even read.

Fortunately there was a panel studying just this question, and it may be read in Sandia Laboratory‘s publication, Expert Judgment on Inadvertant Human Intrusion into the Waste Isolation Pilot Plant, 1993. I love reading this thing; I should just get a copy somehow. My favorite part is the designs for a purposely inhospitable architecture that will last 20,000 years, and also the 3 panel “See Dick Die” cartoon.

The Clock of the Long Now is designed to tell accurate time for 25,000 years. The clock has been designed to withstand the fall of civilization; it can be fixed with bronze-age tools.

Moment of Zen #8

looky

TOBY: http://www.meetup.com/
BRIAN: what is this
TOBY: you ever hear of meetups?
BRIAN: they look to be largly political
TOBY: you can create meetings for just about anything
TOBY: there is one in there for goth
TOBY: and another for chihuahuas
BRIAN: excellent
BRIAN: for petting or eating?
TOBY: who knows
TOBY: maybe we should attend meeting
TOBY: and say, I think the legs taste the best
BRIAN: yeah and get pelted with tiny sweaters