Hacker News Reader

Comment by lopatin | Hacker News Reader

Same here. I was selling a PHP+MySQL script and about 20% of my customers couldn't install it despite my verbose instructions. I don't really blame them, I shouldn't have been making non-technical web masters navigate a cPanel account and mess with PHP in the first place. I couldn't possibly provide personal technical support to everyone in need so I granted a refund to anyone who didn't get it working.

As a side note, this is the reason I hate PayPal. They didn't like my refund percentage apparently and simply banned my account. It sucked being treated like some scammer by countless customer support reps just because I couldn't provide tech support to all customers and had a higher refund rate. It's all for the best now though :) Subscription model + Stripe is a godsend.

View on HN

We have a vendor of some mailing list software that you install your save (basically a tarball of php code). If we have an issue with it, they basically refuse to help unless we give them ssh access to our server.

Stupidly we have this mailing list software running on our production web server (the same one our customers use to access our apps), so we can't do that. I mean I trust the guy to not go in an install a backdoor or delete all of our files (maybe I shouldn't trust him?) but I've always wondered what the liability is there.

Would we basically have to prove he did something malicious if our server crashed the next day or turned into a spam box?

That sounds like a sticky situation. I don't think it's a matter of trust, but just a matter of principle for me. He can be the most trustworthy guy ever, it still doesn't mean it's a good idea to give him ssh access to your business. That should be sacred. Because of the fact that they are requesting ssh access, I would try to migrate to another mailing list service, probably something hosted like Mandrill or SendGrid. I realize that is probably much easier said than done for you guys, but I think it's necessary in the long run.

In the meanwhile, I guess you can mitigate risk by making strict permissions for the user they ssh in with. Are they usually manipulating data on the production server, or changing code? If it's just code, you can give them access to a development server and push code to production by yourself after you've done a review.

You don't trust him with ssh access to your server, yet you trust him to run arbitrary code there. That doesn't make any sense.

> You don't trust him with ssh access to your server, yet you trust him to run arbitrary code there. That doesn't make any sense.

When people say "ssh access" they usually mean root. The software that's running there, if the server is properly set up, will be running on a restricted account with restricted privileges. Now, granted, even with that there can be quite a bit of damage, but not as much as giving somebody root access to your system.

That's indeed the core of the problem. If your server is properly set up, you probably have one unix user per app, with other home directories not traversable and you can simply add a temporary ssh key. But then again, if customer have difficulties to install your software being just a php / mysql app, chances are great his server is not properly set up.

I think that the proper solution to any paid, self hosted application would be ... to provide hosting for less tech savvy users. Granted, your main selling point is to be self hosted, but you should not alienate people who are interested just by the product itself. And having a less costy per month plan is a great mean to let users try your app before deciding they should takes time or money to educate or hire a sysadmin.

2 days ago I cancelled Basecamp. Why? Pricing. Duet looks beautiful. I agree, hosting for less tech savvy users would be great. The pricing is great for self-hosted. Frankly, the SaaS adds up quickly, and my hurdle rate is 10x (I have to save 10x the comparable annual dollar cost for Saas it to be sustainable).

Indeed, I was not trying to evangelize SaaS/PaaS :) I'm quite bored of seeing clients wasting founding money on heroku stack, where they first pay incredible amount to have unix processes, then pay a service to have email sending, then one to host uploads, then one to have logging, then on to monitor their app, then they rent a dedicated server anyway because they have specific needs ...

My point is more that it's probably a good thing to provide both webservice and installable app (github, with its github enterprise is a very good example of that, even if way too expansive), to let user choose your product based on what it does instead of what are its requirements and implications.

Yeah ok, but then a) the software should probably not run under root. In fact it should probably not run at all, if you haven't done any kind of audit on it/the developer.

And b) assuming you have done your due diligence on the developer in the first place, why not trust him with access to your machine? And again - you shouldn't grant him root of course, but a shell account with privileges similar to the application would be fine.

But really - Purchasing a script from some back-alley developer you have no knowledge of and placing it on your production server? That's the reckless part.

I recommend using acct to monitor the server in addition to limiting the vendor's user. If something happened, you would have a very clear picture of all users' actions in addition to some statistics about system health.

Reply on news.ycombinator.com