5 ms·

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 shou

by lopatin 13y ago

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.

bluedino 13y ago
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?
- lopatin 13y ago
  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.
- troels 13y ago
  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.
  - maratd 13y ago
    > 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.
    - oelmekki 13y ago
      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.
      - Lisa2000 13y ago
        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).
        oelmekki 13y ago
- 1123581321 13y ago
  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.

by lopatin 13y ago

bluedino 13y ago

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?

lopatin 13y ago
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.
troels 13y ago
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.
- maratd 13y ago
  > 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.
  - oelmekki 13y ago
    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.
    - Lisa2000 13y ago
      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).
      - oelmekki 13y ago
1123581321 13y ago
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.