every example I tested is broken on www.phpimagick.com about imagickdemos HOT 6 CLOSED

Thanks.

You're right, site couldn't connect to redis, and the status monitor failed to trigger an alert...

Site is back up now.....however I have a horrible suspicion that it may be compromised somehow. It maybe need to be rebuilt.

Got any advice on how to detect compromised servers.....?

from imagickdemos.

First and most important, thanks for getting the examples back online.

Got any advice on how to detect compromised servers.....?

That would be nice.

The problem is, at most only known compromises can be detected, which still leaves the possibility of an unknown compromise. And of course the highest priority to someone who compromises a server is attempting to hide the compromise before it is detected.

I am sure that does nothing to assuage your horrible suspicion. At least we can commiserate. I treat all systems with suspicion.

Assuming the problem is not a compromise and is redis related, it appears to me that phpimagick.com is static content that doesn't require any database- SQL, NoSQL, or otherwise. Perhaps you could just serve up html without redis? I doubt that redis can beat apache's caching for static content, especially if your redis config requires contacting a separate server.

Just a suggestion and I hope it does not assume too much to be useful.

As an aside (and I bet you just love asides on the issue tracker...), as a newcomer to imagick (but not ImageMagick in a larger sense) it feels like a tutorial for "new Imagick()" and constructors for the other types in the navigation bar (ImageMagickDraw, ImageMagickPixel, etc.) would be handy. It was quite a scavenger hunt finding a tutorial that showed how to create a new image in memory, vs. loading one from disk, despite "new Imagick()" being the simplest possible constructor. The natural place for such tutorials feels like the pages that index the respective objects' methods.

from imagickdemos.

Perhaps you could just serve up html without redis?

No. I have the image processing done as a background job, both as security but also to prevent DOS attacks. Some of the images take ages to process, so having them processed as a background job prevents the web frontend from being locked up processing a few images.

I'm actually not sure it is compromised today.... the box was compromised a few weeks ago and was using huge amounts of bandwidth, and I had to destroy and recreate the box.

Today I'm just seeing slightly odd bandwidth usage:

I'm a reasonably competent software developer....but I hate managing boxes.

With regard to the constructor examples, I've opened a separate issue for you to submit some words/code there.

from imagickdemos.

I'm a reasonably competent software developer....but I hate managing boxes.

I'm similar except I would hesitate to call myself competent. ;) Seriously, though, I am confident in your expertise. imagick is an a most useful piece of software and it probably powers a lot of backends unremarked and unsung.

About running the image processing as a background job, have you considered running a php script as a cron job? That could prevent users from deciding when / how the processing occurs without introducing redis as an additional point of failure.

from imagickdemos.

have you considered running a php script as a cron job?

People use cron until they learn about Supervisor.

The setup of the jobs is in: https://github.com/Imagick/ImagickDemos/tree/master/containers/background_worker That's probably the most reliable part of the site.

Thanks for the kind words.

from imagickdemos.

There are any number of process babysitters but what I like about cron is it is already installed and has been field-tested since 1975 so it is unlikely to be the culprit when a system of which it is a component fails of a sudden.

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."

― C. A. R. Hoare

from imagickdemos.