New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Do you think it's reasonable that the customer performs any troubleshooting tasks they would want to perform in the guest OS instead of giving them access?
If they’re willing to do that, sure. But I know I wouldn’t do system administration by proxy, personally. I don’t always know what command I’m going to want to run next, and what might have been a 30 minute job could become a 3 week ticket if the user and admin aren’t on the same schedule.
Don't you think you should have done that before approaching support?
Its unmanaged yes? So, really you need to troubleshoot everything and then provide them with the results to escalate it further.
Generally asking support is my last line of action. I attempt everything and seek outside help before going to support and if I had to go to support and they then asked for the password I would reply with ssh of course.
Knowledge is king. You can only expect support to reply with what you present them.
Some providers wouldn't even entertain having a look.
Did you read any of what I have written?
All I see here is you whining on LET like others have done before you.
Good luck.
It's a shame that almost every discussion on this forum there's people like you who just participate to attack, offend, and bring no value to the conversation.
@jar already told you that some clients (more like most) requires handholding for basic things. People here have no idea how to change IP address inside VM. Do you really expect provider to have 18581758178587 steps checklist ready to show a client to check something for them... most likely with a YouTube video showing all the steps because reading is too hard?
They asked you for password to do it themselves and it will take (if decent support) 2 minutes for a support agent rather than 185 tickets responses because YouTube video was done on version 1.6, now it's 1.72 and you need to adjust version path in /etc/program/1.6/config.ini to /etc/program/1.72/config.ini.
Have you ever (even hobby) tried to support some non-technical people? They just copy-paste instruction, they have no idea what they are doing. Even better - if there is 12 steps to do and on step number 2 copy-pasted command return BIG RED "COMMAND FAILED" they will still process to do steps 3-12, report you back "NOT WORKING FIX PLEASE" and ONLY if you ask them some questions you will find out that step 2 returned BIG RED FAILED.
--
Tell them no, ask them what else you can do, ask them if you can do that for them manually and proceed with 12 ticket responses. If they say nothing can't be done and NO PASSWORD NO HELP then rage quit.
maybe it's the way you start and formulate your discussions, ever thought about that?
as a reader it often feels that you are trying to open a topic each day just to open a topic each day. this quickly makes it look like quantity over quality.
on top the way you write is not like asking a genuine question but writing some prejudiced, click baity text about 'how could they'.
you seem to be seeking attention, acting surprised, waiting for people to chime in on your prejudice but ignoring question about real context.
I guess the whole convo in your ticket was like:
and that's probably about it. nothing to get offended by, but rather a plain offer to help from a friendly support guy which does no harm and can be rejected at any time. he did nothing secretly but everything open and direct. what else would you want?
maybe the wording could have been a little different. asking for access instead of plainly asking the password or whatnot.
but in the end it's like going to a dealer you recently bought a car from, telling them it suddenly stopped three times last night and they ask you to give them the keys for a testdrive to investigate. maybe they snoop into your belongings in the trunk while driving around?
obviously there is no black/white answer to that question 'What do you say to a provider who asks the password?' and you know it. there are tons of situations where in the right context this question can be totally legit and there will be also enought situations where it is not. no need to act surprised or are you really that naive?
to decide in your case we still lack the information about which way your conversation really took in that ticket of yours. but you weren't actually asking about that but formulated a generic question stirring emotions, didn't you?
I change the password to something temporary and random and give it to the provider. As long as the provider has the decency to ask for it (while we know he can login without it), it means intentions are not malign and we have some mutual respect going on.
Besides, if I don't trust a provider, maybe I should not be with that provider in the first place.
My car breaks down,
I go to a mechanic,
Mechanic asks me to keep my car in his garage for 2 days so he can fix it,
Do I refuse it? No.
Instead I empty my car's dashboard, keep all the valuables out of my car and carry it to my house.
Leave the car and keys to the mechanic and collect the car 2 days later.
I am facing a similar situation. I have two services that I paid for a three-year term upfront. In the past, they consistently handled the load without any issues. However, in the past six months (since they introduced a promotion), my VPS instances have been frequently going offline and restarting automatically. This has forced me to migrate my services elsewhere. What's most unreasonable is that even when the services become unusable, the provider takes no action except advising to reduce CPU usage to below 30%.
Their contract is for a three-year period, and they do not offer refunds. This means that I am obligated to endure the restrictions of this service, which offers a poor quality compared to its price. After the three years are over, I will be terminating my relationship with them.
I think this thread is just funny.
If you were in a IT position before, you will know there are just millions of ways things can go wrong. Screen sharing is the minimum to do any kind of supports (that cannot be done on my side via other remote means) or else the whole support just take forever.
Replies by @JabJab and @jar is just spot on and exactly the issue.
When provider ask for your credentials even on an unmanaged service, treat this as an offer for help, not an attempt to steal your data. It is kinda sad how some kind gestures were treated as malicious nowadays.
In fact I find it great that GreenCloud offered to help since for most unmanaged VPS providers they might just close the ticket as it is not within their support level to fix for you.
You have to somehow trust the party you store your data with. If you really think they will be interested with your data then just go for larger companies. The larger it is the less interested they are with your data.
I think the real question is this: If you don’t trust them with your server, why do you pay them to host your server in the first place?
Paying for a KVM VPS is basically saying ”here’s some money, give me the resources I’ve paid for, and deploy it on your hypervisor that you have full access to and can do whatever on, I trust you with my data and you trust me on your network.”
If you can’t share a temporary login to the server, you shouldn’t have been with the provider at all.
So you're saying it's better for the host to give support personnel enough access to do this (but not all levels of support should have that kind of access to the node) and you're okay with that? Think it through - that would be the same danger as giving out your password. I said temporary password.
I think temporary password should be implied, but when asking a customer for root access to their VPS I can totally wrap my mind around why support wouldn’t specify for the user to set a temporary password. My logic path being:
That logic could also explain why not to open with giving them an SSH key, just let the customer suggest it if they’re intelligent enough.
You know, shortest paths to resolution. Ask the least of the customer by default in an assumption that they’re not the least bit talented admins. Most honestly aren’t.
I think you can get a VPS from another provider and transfer your current VPS to another LET member. There will still be some BF/CM sales.
Understood, I stand corrected, I was thinking about what I would do if I desperately needed resolution for a VPS (thankfully I can afford multiple vps/providers) and obviously take precaution as in removing any data I didn't want provider to have access to. I thought maybe this was a lower level support tech trying to be ambitious scenario which likely goes against the norm and asking for login. It does make the provider look bad that they may not have taught the techs properly unless of course thus gets even deeper in a scandal that the tech is doing something shady.
I in most cases agree with this advice on the dedis
Some months ago, I encountered a problem that newly assigned IPv6 address does not work.
I opened Ticket #278516 - cannot transmit from new IPv6 address.
They asked for the password first, before trying any troubleshooting.
You can see a transcript of this ticket here:
The transcript is altered in these aspects: IP/MAC/email/person-name are anonymized; automated "Hello, We will check and get back to you soon." replies are deleted.
Everything else reflects what's in the original ticket.
This is the only technical ticket that I had discussed with @NDTN.
The speed of resolution is impressive, but the immediate demand of password is unpleasing.
Just seen this thread and I would like to point out several things here:
1. @vitobotta I have taken a look at your ticket, it seems that the issue happened since your reinstallation to a specific OS and services installed (containters, etc). We cannot reproduce this issue on the other VPS as installation/software/usecase would not be the same. That's why our staff asked for the password to check if anything is wrong on the VPS. If you are not willing to provide that, it's fine. You can investigate the issue further by reinstall to other OS templates, reinstall your software, etc.
2. We cannot and will not access a customer's VPS without their permission. If data is important to you then the simple process would be backing up the data, reinstall the VPS before giving out the credentials.
3. @yoursunny your ticket was about a completely different case about IPv6 issue that 99% tickets that we have received can be resolved by a correct configuration.
In this case, customer service should temporarily (free for 24 hours) grant a snapshot/backup slot to the service, so that the customer wouldn't have to spend hours reinstalling the server.
My configuration was/is correct - it worked for many months.
Instead of actually reading my report, the first few replies just "jump to the conclusion" of my configuration being wrong.
I offered complete steps to reproduce the bug in rescue but the technician won't listen until several hours later.
If only SolusVM supports that.
I gave technician permission to reinstall the service when they wanted to access, provided that they take a backup on the hypervisor side and subsequently restore the backup after they have accessed the service.
I even linked to the steps on how to perform a backup on the hypervisor side.
It will not work on an unmanaged services as it will require a lot of admin time. You are advised to take your own backup in that case instead.
I remember their transfer is free for the first time. Also, idling the VPS doesn't yield any benefits, but if you transfer it at a discounted rate, you can allocate it toward the cost of purchasing the next VPS.
Doing the manual backup/restore is necessary but only if the technician demands to access the server that is installed on the main disk drive and not in rescue mode.
The admin time of this procedure shall be considered as part of the cost of resolving a ticket, but it is needed only if the technician cannot resolve the issue without accessing the installed server.
In most cases, the issue can be resolved without accessing the installed server, in environments such as:
In this ticket, the technician eventually went to the third option and isolated the root cause.
What I'm saying is that, asking to access the installed server should be the last resort, not the first strategy of problem resolution.
wtf are you talking about? Have you ever done Tech Support before? How much of a drama queen are you? You sound like a nightmare customer.
For Support to ask for a password, it can be:
1. The customer is an idiot
2. The customer isn't providing useful troubleshooting information
3. The customer is suspicious AF
4. They don't see any problem on their end, suspect the issue is PEBKAC
In most cases, customers are happy (and pay extra) for Support to take over and fix shit ASAP instead of going back and forth pulling teeth.
Edit: scrolling further it sounds like the agent didn't believe he checked the logs well enough and wanted to check himself. In those cases, you need to say what the logs indicated to show you've looked at them. I can definitely tell when someone is lying to me (over the phone) about having checked logs when they haven't. I'm sure they can tell through text with experience, too.
Can you read the first message (at the bottom) of my ticket and classify me into one of these cases?
Did they message you back with an invoice for managed service? I'd refund you for being a needy customer. Telling them your OS can't login with a password is a big red flag. You know they have a console, right?