[khiltd]

So you didn’t actually look at the POST data or the script sources to see what was going wrong, yet you’re sure the issues lie elsewhere because Symantec’s documented troubleshooting procedure [b]didn’t[/b] work? I don’t follow the logic there.

Symantec’s chosen to deploy a web app in this case, and even if they’ve “compiled” their PHP sources to protect their amazing trade secrets (which does not appear to be the case), you still have plenty of opportunities to patch in. If you want it fixed within the next 5 years you should probably get a qualified PHP engineer out there to do your troubleshooting for you because finding the cause of the problem would likely be a trivial task for them. Symantec doesn’t sell enough Mac software to warrant supporting it.

[khiltd]

Google finds plenty of documentation on how to do this manually, and also tools like this:

http://www.hornware.com/sharepoints/

[khiltd]

Looks like fail2ban is a Python script that sets up ipfw rules based on the results of log parsing. What part of it are you finding doesn’t work on OS X?

[khiltd]

The file_put_contents function is not available in PHP 4. You’ll have to manually create the file, open the file, write the data to the file and close the file.

[khiltd]

[QUOTE][u]Quote by: bentoms[/u][p]Thanks.

The HTTPD access_log is filled with:

10.44.62.34 [09/Apr/2008:17:44:49 +0100] “POST /sacm/ReportStatus.php HTTP/1.1” 200 3

10.44.48.20 [09/Apr/2008:17:43:45 +0100] “POST /sacm/ReportStatus.php HTTP/1.1” 200 4

Any ideas as to what they might mean??
[/p][/QUOTE]

Those are HTTP POST requests. You’ll need to look at the POST data in order to duplicate the problem. It would probably be easiest to fire up an output buffer at the top of ReportStatus.php, throw a [b]var_dump($_POST);[/b] after it and then write the contents out to a file. Assuming you’re running PHP 5:

[code][/code]

Completely untested, but it looks about right.

[khiltd]

Well it looks like the implemented the entire thing as a basic web service, so it should be fairly easy to either listen in on the port or check your Apache logs to see what the clients’ requests to the server look like. You should then be able to duplicate them with curl, look at the responses, and figure out what’s going wrong.

Given the number of Mac viruses out there, it might be simpler to just pull the plug on Symantec; most people did years ago.

[khiltd]

Er… chmod -R? Or are you asking for something else?

[khiltd]

Yes, that is what I’m saying. MacBuddy will run whenever it’s told to regardless of what’s on the drive.

[khiltd]

And those errors would be…?

[khiltd]

What you have there would not have actually accomplished this on any version of OS X. Software installers routinely place things in more directories than you could ever hope to account for. In no particular order, some of the things that can lead to the unprovoked execution of non-factory default code are:

Address Book Plug-Ins
Contextual Menu Items Plug-Ins
Kernel Extensions
Application Services
Input Managers
Internet Plug-Ins
LaunchAgents
LaunchDaemons
LoginPlugins
Preference Panes
QuickTime Plug-Ins
Startup Items
SyncServices Schemas
SystemConfiguration Plug-Ins
Widgets
cron jobs
Spotlight Importers
QuickLook Plug-Ins

Even if you manage to find them all, figuring out which ones can be blown away without any ill-effects is not something you can script very easily since accurate bundle identifiers are not mandatory. If you need to re-flash a machine to its out-of-the-box state then you’re better off either doing a reinstall or using one of the various drive imaging utilities which can automate the process for you.

[khiltd]

> ssh -v
OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006

[khiltd]

It shouldn’t touch anything in /opt, but it may break configs that are stored elsewhere. You’d have to look inside the packages and see what they do.

[khiltd]

[QUOTE][u]Quote by: SpeedDemon[/u][p]The fixed width problem was only a small part of problems with the teams server. And yes, I know how to edit the CSS layouts to change the the appearance, but there should be a simple setting in the preferences to adjust these kinds of things.

I clearly more upset with the fact that it pretty much has to be used IN SAFARI. Only about 1% of the users I administer use Safari with most using IE7, and pretty much the rest using Firefox. The Wiki works in neither of the two MAJORITY BROWSERS.[/p][/QUOTE]

If web design could be reduced to a simple setting in the preferences there’d be far fewer horrible looking websites in the world. The number of ridiculous JavaScript hacks and workarounds that are required to make a standards compliant layout look anything approaching decent in your MAJORITY BROWSERS are a complete waste of time for anyone who caters primarily to Mac users–like Apple. If you do not cater primarily to Mac users, then investing in an OS X Server solution would probably not be the most sensible expenditure in the world.

[khiltd]

Wordpress is very poorly written code that is riddled with inflexibilities and security holes. What’s worse, their installation procedure actually has you place password laden configuration files within the public document root. One tiny slip up in your Apache configuration and the entire world can get into your database.

[khiltd]

It’s difficult to see what it is we’re supposed to be comparing there since I’m not apt to grab a calculator and work out the percentages myself, but if you’re seeing a discrepancy it could be a difference in the way block sizes are being calculated.

[Author]

Posts