<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_26_1520255</id>
	<title>Preventing My Hosting Provider From Rooting My Server?</title>
	<author>Soulskill</author>
	<datestamp>1261848300000</datestamp>
	<htmltext><a href="mailto:setuid@gmail.com" rel="nofollow">hacker</a> writes <i>"I have a heavily-hit public server (web, mail, cvs/svn/git, dns, etc.) that runs a few dozen OSS project websites, as well as my own personal sites (gallery, blog, etc.). From time to time, the server has 'unexpected' outages, which I've determined to be the result of hardware, network and other issues on behalf of the provider. I run a lot of monitoring and logging on the server-side, so I see and graph every single bit and byte in and out of the server and applications, so I know it's not the OS itself. When I file 'WTF?'-style support tickets to the provider through their web-based ticketing system, I often get the response of: 'Please provide us with the root password to your server so we can analyze your logs for the cause of the outage.' Moments ago, there were three simultaneous outages while I was logged into the server working on some projects. Server-side, everything was fine. They asked me for the root password, which I flatly denied (as I always do), and then they rooted the server anyway, bringing it down and poking around through my logs. This is at least the third time they've done this without my approval or consent. Is it possible to create a minimal Linux boot that will allow me to reboot the server remotely, come back up with basic networking and ssh, and then from there, allow me to log in and mount the other application and data partitions under dm-crypt/loop-aes and friends?"</i>
Read on for a few more details of hacker's situation.</htmltext>
<tokenext>hacker writes " I have a heavily-hit public server ( web , mail , cvs/svn/git , dns , etc .
) that runs a few dozen OSS project websites , as well as my own personal sites ( gallery , blog , etc. ) .
From time to time , the server has 'unexpected ' outages , which I 've determined to be the result of hardware , network and other issues on behalf of the provider .
I run a lot of monitoring and logging on the server-side , so I see and graph every single bit and byte in and out of the server and applications , so I know it 's not the OS itself .
When I file 'WTF ?
'-style support tickets to the provider through their web-based ticketing system , I often get the response of : 'Please provide us with the root password to your server so we can analyze your logs for the cause of the outage .
' Moments ago , there were three simultaneous outages while I was logged into the server working on some projects .
Server-side , everything was fine .
They asked me for the root password , which I flatly denied ( as I always do ) , and then they rooted the server anyway , bringing it down and poking around through my logs .
This is at least the third time they 've done this without my approval or consent .
Is it possible to create a minimal Linux boot that will allow me to reboot the server remotely , come back up with basic networking and ssh , and then from there , allow me to log in and mount the other application and data partitions under dm-crypt/loop-aes and friends ?
" Read on for a few more details of hacker 's situation .</tokentext>
<sentencetext>hacker writes "I have a heavily-hit public server (web, mail, cvs/svn/git, dns, etc.
) that runs a few dozen OSS project websites, as well as my own personal sites (gallery, blog, etc.).
From time to time, the server has 'unexpected' outages, which I've determined to be the result of hardware, network and other issues on behalf of the provider.
I run a lot of monitoring and logging on the server-side, so I see and graph every single bit and byte in and out of the server and applications, so I know it's not the OS itself.
When I file 'WTF?
'-style support tickets to the provider through their web-based ticketing system, I often get the response of: 'Please provide us with the root password to your server so we can analyze your logs for the cause of the outage.
' Moments ago, there were three simultaneous outages while I was logged into the server working on some projects.
Server-side, everything was fine.
They asked me for the root password, which I flatly denied (as I always do), and then they rooted the server anyway, bringing it down and poking around through my logs.
This is at least the third time they've done this without my approval or consent.
Is it possible to create a minimal Linux boot that will allow me to reboot the server remotely, come back up with basic networking and ssh, and then from there, allow me to log in and mount the other application and data partitions under dm-crypt/loop-aes and friends?
"
Read on for a few more details of hacker's situation.</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559246</id>
	<title>Re:If they do this..</title>
	<author>Anonymous</author>
	<datestamp>1261829220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I agree, It sounds like the bridge is already burned. Any web server should be run in a virtual machine, sandbox, or jail and not unprotected.Secondly it would be advisable to disable password logins and use keys only. There are also several programs to detect multiple login attemps and then disable a range of ips from logging in again.  If they want access to logs, it sounds like someone allegedly wanting to cover their tracks. I would also image the server asap.  if for no other reason than for evidence.</p></htmltext>
<tokenext>I agree , It sounds like the bridge is already burned .
Any web server should be run in a virtual machine , sandbox , or jail and not unprotected.Secondly it would be advisable to disable password logins and use keys only .
There are also several programs to detect multiple login attemps and then disable a range of ips from logging in again .
If they want access to logs , it sounds like someone allegedly wanting to cover their tracks .
I would also image the server asap .
if for no other reason than for evidence .</tokentext>
<sentencetext>I agree, It sounds like the bridge is already burned.
Any web server should be run in a virtual machine, sandbox, or jail and not unprotected.Secondly it would be advisable to disable password logins and use keys only.
There are also several programs to detect multiple login attemps and then disable a range of ips from logging in again.
If they want access to logs, it sounds like someone allegedly wanting to cover their tracks.
I would also image the server asap.
if for no other reason than for evidence.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559866</id>
	<title>Use this howto</title>
	<author>Geheimagent</author>
	<datestamp>1261836240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Use this <a href="http://gpl.coulmann.de/ssh\_luks\_unlock.html" title="coulmann.de" rel="nofollow">howto</a> [coulmann.de].</htmltext>
<tokenext>Use this howto [ coulmann.de ] .</tokentext>
<sentencetext>Use this howto [coulmann.de].</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561174</id>
	<title>Colo is your answer</title>
	<author>Anonymous</author>
	<datestamp>1261856340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Based on your previous replies, you have said that the server is not yours.<br>It really doesn't matter WHO the server belongs to after that, it simply is not yours.<br>Whether they rent it, re-sell it or whatever, it still is not yours.</p><p>Honestly, I don't care how "clued" you are, they are not wrong in asking for the root password to diagnose a problem which you claim is happening with their hardware. ( I say "their" since they are in a contract with someone else over this server and you are not in that contract). If you feel they are that inept, you should have kept detailed notes and asked to speak to management to voice concern about their previous ineptness to see if a more senior technician can work on the issue.</p><p>Keep in mind that a good business would at least want to try to see if there is a problem with the machine in question so that they can they replace it with those they are renting from. At the company where I previously worked, they rented their machines for a period of time and that worked out better than buying new machines every few years. If anything went seriously wrong during that period, it was a matter of shipping the machine back and getting a new one at the same rental fee.</p><p>Now, as to them locking you out and all that, I'd have to see YOUR contract with them to know what is right and wrong regardless of how inept you think they are.<br>If your contract allows this behavior, then you really have no room to complain.</p><p>If they hardware was determined to be the issue, who knows if they had the exact hardware to stuck you back on (since they rent the hardware). Its not clear and I honestly do not feel like reading through more replies here.</p><p>It sounds like you made things harder on yourself than needed. But you chose to pay the 35/day KVM switch and fixed things yourself (good for you). BUT, that was YOUR CHOICE in not giving up your password.</p><p>I also question WHY they would try to hide their tracks on rooting your box as they did. If its in their contract, so what? Hiding it makes it suspicious.</p><p>At any rate, the short version is what I said in the title.</p><p>You need to get a machine and colo it. Get the necessary equipment as has been previously stated and at that point, you have legal recourse. As it stands, I don't know what re-course you have as that depends on your contract with them.</p><p>Example: As a company I worked for, NOT providing the requested information and/or logs was reason enough to close an open trouble ticket. We normally gave our best effort since some situations existed where people genuinely could not do so (security clearances, etc). Once we hit a point where that info was non-optional, they customer had a choice to make and that was do what they had to in order to get the logs or close the ticket.</p><p>Now is the time for you to continue to make your choices.</p><p>* Abide by their rules and fess up the password (pursuing through management as needed)<br>* pay KVM charges as needed to avoid giving the password<br>* change providers that might more suit your whims (good luck on that)<br>* COLO</p></htmltext>
<tokenext>Based on your previous replies , you have said that the server is not yours.It really does n't matter WHO the server belongs to after that , it simply is not yours.Whether they rent it , re-sell it or whatever , it still is not yours.Honestly , I do n't care how " clued " you are , they are not wrong in asking for the root password to diagnose a problem which you claim is happening with their hardware .
( I say " their " since they are in a contract with someone else over this server and you are not in that contract ) .
If you feel they are that inept , you should have kept detailed notes and asked to speak to management to voice concern about their previous ineptness to see if a more senior technician can work on the issue.Keep in mind that a good business would at least want to try to see if there is a problem with the machine in question so that they can they replace it with those they are renting from .
At the company where I previously worked , they rented their machines for a period of time and that worked out better than buying new machines every few years .
If anything went seriously wrong during that period , it was a matter of shipping the machine back and getting a new one at the same rental fee.Now , as to them locking you out and all that , I 'd have to see YOUR contract with them to know what is right and wrong regardless of how inept you think they are.If your contract allows this behavior , then you really have no room to complain.If they hardware was determined to be the issue , who knows if they had the exact hardware to stuck you back on ( since they rent the hardware ) .
Its not clear and I honestly do not feel like reading through more replies here.It sounds like you made things harder on yourself than needed .
But you chose to pay the 35/day KVM switch and fixed things yourself ( good for you ) .
BUT , that was YOUR CHOICE in not giving up your password.I also question WHY they would try to hide their tracks on rooting your box as they did .
If its in their contract , so what ?
Hiding it makes it suspicious.At any rate , the short version is what I said in the title.You need to get a machine and colo it .
Get the necessary equipment as has been previously stated and at that point , you have legal recourse .
As it stands , I do n't know what re-course you have as that depends on your contract with them.Example : As a company I worked for , NOT providing the requested information and/or logs was reason enough to close an open trouble ticket .
We normally gave our best effort since some situations existed where people genuinely could not do so ( security clearances , etc ) .
Once we hit a point where that info was non-optional , they customer had a choice to make and that was do what they had to in order to get the logs or close the ticket.Now is the time for you to continue to make your choices .
* Abide by their rules and fess up the password ( pursuing through management as needed ) * pay KVM charges as needed to avoid giving the password * change providers that might more suit your whims ( good luck on that ) * COLO</tokentext>
<sentencetext>Based on your previous replies, you have said that the server is not yours.It really doesn't matter WHO the server belongs to after that, it simply is not yours.Whether they rent it, re-sell it or whatever, it still is not yours.Honestly, I don't care how "clued" you are, they are not wrong in asking for the root password to diagnose a problem which you claim is happening with their hardware.
( I say "their" since they are in a contract with someone else over this server and you are not in that contract).
If you feel they are that inept, you should have kept detailed notes and asked to speak to management to voice concern about their previous ineptness to see if a more senior technician can work on the issue.Keep in mind that a good business would at least want to try to see if there is a problem with the machine in question so that they can they replace it with those they are renting from.
At the company where I previously worked, they rented their machines for a period of time and that worked out better than buying new machines every few years.
If anything went seriously wrong during that period, it was a matter of shipping the machine back and getting a new one at the same rental fee.Now, as to them locking you out and all that, I'd have to see YOUR contract with them to know what is right and wrong regardless of how inept you think they are.If your contract allows this behavior, then you really have no room to complain.If they hardware was determined to be the issue, who knows if they had the exact hardware to stuck you back on (since they rent the hardware).
Its not clear and I honestly do not feel like reading through more replies here.It sounds like you made things harder on yourself than needed.
But you chose to pay the 35/day KVM switch and fixed things yourself (good for you).
BUT, that was YOUR CHOICE in not giving up your password.I also question WHY they would try to hide their tracks on rooting your box as they did.
If its in their contract, so what?
Hiding it makes it suspicious.At any rate, the short version is what I said in the title.You need to get a machine and colo it.
Get the necessary equipment as has been previously stated and at that point, you have legal recourse.
As it stands, I don't know what re-course you have as that depends on your contract with them.Example: As a company I worked for, NOT providing the requested information and/or logs was reason enough to close an open trouble ticket.
We normally gave our best effort since some situations existed where people genuinely could not do so (security clearances, etc).
Once we hit a point where that info was non-optional, they customer had a choice to make and that was do what they had to in order to get the logs or close the ticket.Now is the time for you to continue to make your choices.
* Abide by their rules and fess up the password (pursuing through management as needed)* pay KVM charges as needed to avoid giving the password* change providers that might more suit your whims (good luck on that)* COLO</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30589826</id>
	<title>cant you just</title>
	<author>teknosapien</author>
	<datestamp>1262099940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><br>Have your logs set in a password protected web space 
<br>I'm not really sure what O/S your running - but I know on BSD copying logs to a readable format on a web page is fairly straight forward 
<br> Make sure you put them all there and turn on verbose logging ( if you have the disk space) 
<br>oh you want to see the logs here's the address 
<br>there is no need to give your provider root access to your machine
<br>if this isn't acceptable maybe give them only access to read<nobr> <wbr></nobr>/var/log/* or what ever your defined path is 
<br>but to give them the root password <b>Not happening</b> most I would agree to is read only access thought a limited account</htmltext>
<tokenext>Have your logs set in a password protected web space I 'm not really sure what O/S your running - but I know on BSD copying logs to a readable format on a web page is fairly straight forward Make sure you put them all there and turn on verbose logging ( if you have the disk space ) oh you want to see the logs here 's the address there is no need to give your provider root access to your machine if this is n't acceptable maybe give them only access to read /var/log/ * or what ever your defined path is but to give them the root password Not happening most I would agree to is read only access thought a limited account</tokentext>
<sentencetext>Have your logs set in a password protected web space 
I'm not really sure what O/S your running - but I know on BSD copying logs to a readable format on a web page is fairly straight forward 
 Make sure you put them all there and turn on verbose logging ( if you have the disk space) 
oh you want to see the logs here's the address 
there is no need to give your provider root access to your machine
if this isn't acceptable maybe give them only access to read /var/log/* or what ever your defined path is 
but to give them the root password Not happening most I would agree to is read only access thought a limited account</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560112</id>
	<title>Wait a minute!</title>
	<author>Anonymous</author>
	<datestamp>1261839960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I thought Linux was a secure server platform. And these guys are rooting it in a few minutes?</p></htmltext>
<tokenext>I thought Linux was a secure server platform .
And these guys are rooting it in a few minutes ?</tokentext>
<sentencetext>I thought Linux was a secure server platform.
And these guys are rooting it in a few minutes?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557028</id>
	<title>Re:rooted? What does this word mean?</title>
	<author>Manfre</author>
	<datestamp>1261854120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It means that they bypassed the root user password. This is easily accomplished when you have physical access to the machine. It's often used for recovering from a forgotten root password.</p><p><a href="http://www.felipecruz.com/blog\_reset-root-password-linux.php" title="felipecruz.com">http://www.felipecruz.com/blog\_reset-root-password-linux.php</a> [felipecruz.com]</p></htmltext>
<tokenext>It means that they bypassed the root user password .
This is easily accomplished when you have physical access to the machine .
It 's often used for recovering from a forgotten root password.http : //www.felipecruz.com/blog \ _reset-root-password-linux.php [ felipecruz.com ]</tokentext>
<sentencetext>It means that they bypassed the root user password.
This is easily accomplished when you have physical access to the machine.
It's often used for recovering from a forgotten root password.http://www.felipecruz.com/blog\_reset-root-password-linux.php [felipecruz.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556950</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557944</id>
	<title>he denied access, and they broke in -- jailtime</title>
	<author>Anonymous</author>
	<datestamp>1261818600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>imminent, theres no other way about it. Even a damn locksmith needs your permission before breaking into your place.</p></htmltext>
<tokenext>imminent , theres no other way about it .
Even a damn locksmith needs your permission before breaking into your place .</tokentext>
<sentencetext>imminent, theres no other way about it.
Even a damn locksmith needs your permission before breaking into your place.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558404</id>
	<title>Better setup</title>
	<author>Anonymous</author>
	<datestamp>1261822500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Soooo, they rooted your server? You're pwned. You need a better setup:</p><p>(ISP lame NW) -- (HW FW, commercial) -- (OpenBSD box with nothing but a FW) -- (Your LEET NW)</p><p>Good luck rooting that!</p></htmltext>
<tokenext>Soooo , they rooted your server ?
You 're pwned .
You need a better setup : ( ISP lame NW ) -- ( HW FW , commercial ) -- ( OpenBSD box with nothing but a FW ) -- ( Your LEET NW ) Good luck rooting that !</tokentext>
<sentencetext>Soooo, they rooted your server?
You're pwned.
You need a better setup:(ISP lame NW) -- (HW FW, commercial) -- (OpenBSD box with nothing but a FW) -- (Your LEET NW)Good luck rooting that!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556940</id>
	<title>Dell-remote access cards</title>
	<author>Anonymous</author>
	<datestamp>1261853460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Get a hosting company that allows you access to a remote access card. Dell servers use a 'DRAC' Dell Remote access card. IBM and stuff have their own.</p></htmltext>
<tokenext>Get a hosting company that allows you access to a remote access card .
Dell servers use a 'DRAC ' Dell Remote access card .
IBM and stuff have their own .</tokentext>
<sentencetext>Get a hosting company that allows you access to a remote access card.
Dell servers use a 'DRAC' Dell Remote access card.
IBM and stuff have their own.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558234</id>
	<title>Re:Stop being a douche</title>
	<author>MistrBlank</author>
	<datestamp>1261820700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem is that many admins still don't understand sudo.</p><p>My asshole boss doesn't understand it either and though I consider it best practice as everyone has come to the conclusion, he still insists it's giving up too many rights on the hosts and he'll never use it.</p><p>But to be honest, I don't understand why you need root or that level of access on a box either.  It works just as easily in the reverse,  as a hosting company they could (should?) provide you logins and just enough access to do what you need to.</p></htmltext>
<tokenext>The problem is that many admins still do n't understand sudo.My asshole boss does n't understand it either and though I consider it best practice as everyone has come to the conclusion , he still insists it 's giving up too many rights on the hosts and he 'll never use it.But to be honest , I do n't understand why you need root or that level of access on a box either .
It works just as easily in the reverse , as a hosting company they could ( should ?
) provide you logins and just enough access to do what you need to .</tokentext>
<sentencetext>The problem is that many admins still don't understand sudo.My asshole boss doesn't understand it either and though I consider it best practice as everyone has come to the conclusion, he still insists it's giving up too many rights on the hosts and he'll never use it.But to be honest, I don't understand why you need root or that level of access on a box either.
It works just as easily in the reverse,  as a hosting company they could (should?
) provide you logins and just enough access to do what you need to.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557580</id>
	<title>No need to give away the root password</title>
	<author>Anonymous</author>
	<datestamp>1261859100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>First and foremost, I agree with the suggestion that most people made... Consider changing providers.   That being said, there are two very easy ways around giving someone your root password:</p><p>- Create a support account with sudo privileges<br>- Have your syslog re-direct the output to a remote server/logging facility</p><p>Both of those solutions are quite easy to implement.  Based on your claim that you log/graph anything that comes in/out of your server, such trivial tasks should be second nature to you.</p></htmltext>
<tokenext>First and foremost , I agree with the suggestion that most people made... Consider changing providers .
That being said , there are two very easy ways around giving someone your root password : - Create a support account with sudo privileges- Have your syslog re-direct the output to a remote server/logging facilityBoth of those solutions are quite easy to implement .
Based on your claim that you log/graph anything that comes in/out of your server , such trivial tasks should be second nature to you .</tokentext>
<sentencetext>First and foremost, I agree with the suggestion that most people made... Consider changing providers.
That being said, there are two very easy ways around giving someone your root password:- Create a support account with sudo privileges- Have your syslog re-direct the output to a remote server/logging facilityBoth of those solutions are quite easy to implement.
Based on your claim that you log/graph anything that comes in/out of your server, such trivial tasks should be second nature to you.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557876</id>
	<title>Re:Stop being a douche</title>
	<author>Anonymous</author>
	<datestamp>1261818060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Im going to have to agree on the douche comment.. On a daily basis i have to deal with people like that.They dont bother to read the terms of service. Fuck up their machines overload it with so much monitoring it starts to trigger their chintzy firewall and then they want us to fix their crap..</p><p>Personally id like to know the provider because im sure there is a flip-side to the story<nobr> <wbr></nobr>..</p></htmltext>
<tokenext>Im going to have to agree on the douche comment.. On a daily basis i have to deal with people like that.They dont bother to read the terms of service .
Fuck up their machines overload it with so much monitoring it starts to trigger their chintzy firewall and then they want us to fix their crap..Personally id like to know the provider because im sure there is a flip-side to the story . .</tokentext>
<sentencetext>Im going to have to agree on the douche comment.. On a daily basis i have to deal with people like that.They dont bother to read the terms of service.
Fuck up their machines overload it with so much monitoring it starts to trigger their chintzy firewall and then they want us to fix their crap..Personally id like to know the provider because im sure there is a flip-side to the story ..</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557138</id>
	<title>How do they Root your Box?</title>
	<author>Athaulf</author>
	<datestamp>1261855260000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Hello,

I work for a very similar company that provides support.  How do they root your box?  If your company is like mine, they can't simply reboot the box and log in via singles to gain root access, so how is it possible that they even get in?  Are you suggesting that they hack it somehow to gain root access?  That would surprise me greatly because no one in this field would care enough to go through the trouble of a sophisticated hack of your server, and besides, if they could do it, so can anyone else.  Because of the hazy situation here, I'm going to assume that you are running this "server" as a VPS as opposed to a dedicated server plan.  If that's the case, then they can easily log into your root account because your server is already run under VMWare.  Chances are they asked you for your password in order to bypass looking up the vzid of your container.  After that, it's typical procedure to restart the container if you're eating up massive resources.  That will usually clear out the http/svn/mysql connections that are eating away at your container, and likely the entire VPS node.  Also, I'm pretty sure that they do retain the legal right for such procedures for the purpose of cleaning up your VPS in order to keep it from taking down the entire node.  Because they can gain root access on your server, VMWare would just eat up more resources, and probably not fix the overall problem at all.  It may keep them from viewing your files, but they'll still restart the container when they check top and see it at a load of 50 or something.

So the next time that your 'server' goes down, ask them if they can tell you exactly wtf happened, and provide some examples so that you can show that you know enough about it to handle a mildly complex answer.  For instance, ask them, "Why did you restart my server, was the load too high?  Is there any way you can help me identify what was causing the server load?", or at the very least optimize PHP and MySQL in your scripts.  If you don't like them logging into you VPS without permission, you really need to be upgrading to an approximately $300/month actual dedicated server.  You may need to anyway, considering that load is most likely the reason that they restart your container.

Regards,
A Pissy Tech Support Lacky</htmltext>
<tokenext>Hello , I work for a very similar company that provides support .
How do they root your box ?
If your company is like mine , they ca n't simply reboot the box and log in via singles to gain root access , so how is it possible that they even get in ?
Are you suggesting that they hack it somehow to gain root access ?
That would surprise me greatly because no one in this field would care enough to go through the trouble of a sophisticated hack of your server , and besides , if they could do it , so can anyone else .
Because of the hazy situation here , I 'm going to assume that you are running this " server " as a VPS as opposed to a dedicated server plan .
If that 's the case , then they can easily log into your root account because your server is already run under VMWare .
Chances are they asked you for your password in order to bypass looking up the vzid of your container .
After that , it 's typical procedure to restart the container if you 're eating up massive resources .
That will usually clear out the http/svn/mysql connections that are eating away at your container , and likely the entire VPS node .
Also , I 'm pretty sure that they do retain the legal right for such procedures for the purpose of cleaning up your VPS in order to keep it from taking down the entire node .
Because they can gain root access on your server , VMWare would just eat up more resources , and probably not fix the overall problem at all .
It may keep them from viewing your files , but they 'll still restart the container when they check top and see it at a load of 50 or something .
So the next time that your 'server ' goes down , ask them if they can tell you exactly wtf happened , and provide some examples so that you can show that you know enough about it to handle a mildly complex answer .
For instance , ask them , " Why did you restart my server , was the load too high ?
Is there any way you can help me identify what was causing the server load ?
" , or at the very least optimize PHP and MySQL in your scripts .
If you do n't like them logging into you VPS without permission , you really need to be upgrading to an approximately $ 300/month actual dedicated server .
You may need to anyway , considering that load is most likely the reason that they restart your container .
Regards , A Pissy Tech Support Lacky</tokentext>
<sentencetext>Hello,

I work for a very similar company that provides support.
How do they root your box?
If your company is like mine, they can't simply reboot the box and log in via singles to gain root access, so how is it possible that they even get in?
Are you suggesting that they hack it somehow to gain root access?
That would surprise me greatly because no one in this field would care enough to go through the trouble of a sophisticated hack of your server, and besides, if they could do it, so can anyone else.
Because of the hazy situation here, I'm going to assume that you are running this "server" as a VPS as opposed to a dedicated server plan.
If that's the case, then they can easily log into your root account because your server is already run under VMWare.
Chances are they asked you for your password in order to bypass looking up the vzid of your container.
After that, it's typical procedure to restart the container if you're eating up massive resources.
That will usually clear out the http/svn/mysql connections that are eating away at your container, and likely the entire VPS node.
Also, I'm pretty sure that they do retain the legal right for such procedures for the purpose of cleaning up your VPS in order to keep it from taking down the entire node.
Because they can gain root access on your server, VMWare would just eat up more resources, and probably not fix the overall problem at all.
It may keep them from viewing your files, but they'll still restart the container when they check top and see it at a load of 50 or something.
So the next time that your 'server' goes down, ask them if they can tell you exactly wtf happened, and provide some examples so that you can show that you know enough about it to handle a mildly complex answer.
For instance, ask them, "Why did you restart my server, was the load too high?
Is there any way you can help me identify what was causing the server load?
", or at the very least optimize PHP and MySQL in your scripts.
If you don't like them logging into you VPS without permission, you really need to be upgrading to an approximately $300/month actual dedicated server.
You may need to anyway, considering that load is most likely the reason that they restart your container.
Regards,
A Pissy Tech Support Lacky</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557628</id>
	<title>Usually more to the story than this....</title>
	<author>Anonymous</author>
	<datestamp>1261859460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>First off, total disclosure - I work for a fairly well know web hosting provider as a system administrator.</p><p>There's basically three plans we have.</p><p>#1 - Managed hosting. We build the box, we manage it, we give you an account to do stuff with. We never give you root. Ever. While I realize the thought of this is anathema to the majority of the slashdot crowd, the bottom line is that webmasters != sysadmin, and there are very few good reasons why a webmaster actually needs root. Obviously in these instances, we can access the machine whenever we want, but as a matter of practice, we don't unless monitoring pops and alert, or a customer submits a ticket. If there's going to be downtime, we try our damndest to work out a time with the customer, but some things (eg, failed drives in an array) constitute bringing the server down without prior customer contact.</p><p>#2 - Unmanaged hosting. We build the box, install whatever OS you want on it, and then turn over root. We do not monitor the box except for ping (and if you firewall off ICMP, we'll turn that off too), and we don't touch the box without a specific request from the customer. If the customer wants us to touch the box, it's a very exorbitant hourly rate (except for hardware failure, as the customer is renting the box from us, we'll replace hardware at no charge, but any work on the server itself outside of that is billable). For these boxes, we would obviously do the same thing with as the OP - we ask for the root password. I'm perfectly ok with providing our public key as well, but most folks would rather just turn over the root password and be done. Occasionally, we do have to root these boxes - either because the customer has forgotten the root password, or because the customer has received a complaint of doing something illegal (like running copyrighted torrents) on the box, and we're forced to investigate to cover our own year. But for the most part, we don't ever want to touch an unmanaged box if we can possibly avoid it. Giving unskilled people root access who break their servers and then want us to fix it is not fun, hence the very large deterrent of the hourly rate. It prevents folks from choosing an unmanaged server just to save a few bucks and then running to us every time something goes wrong.</p><p>#3 - Colocation. You supply the hardware, or you can buy/rent hardware from us. Generally folks will supply their own, and we just drop their network feed into their cage and they take it from there. I can count on one hand the number of times I've had to touch our colo hardware over the years, and if I'm using the right finger, I can make a rude gesture while I'm doing said counting. Generally folks who choose a colo option know what they're doing, and don't need us, and only call if there's an event that's actually beyond their control, like a network issue.</p><p>So honestly, I would take the OP with a grain of salt. If he's got his machine walled off so that only he can touch it on a regular basis, but he keeps opening tickets on a regular basis wanting to know exactly what happened, you're not leaving the hosts tech staff with alot of options. If you're suffering outages, it's a binary question as to who's fault it is - it's either the providers (whether it's network, core internal servers such as DNS, or the like) or it's your servers. Presumably the host is going to know when it's their problem, so if they're asking to take a look at your server, that means the problem is probably actually your server, and not their network. The OP either needs to lose the ego and give up the access or fix his own problems. I suspect that if the OP were to change hosts, the tech staff would not be sorry to see him go</p></htmltext>
<tokenext>First off , total disclosure - I work for a fairly well know web hosting provider as a system administrator.There 's basically three plans we have. # 1 - Managed hosting .
We build the box , we manage it , we give you an account to do stuff with .
We never give you root .
Ever. While I realize the thought of this is anathema to the majority of the slashdot crowd , the bottom line is that webmasters ! = sysadmin , and there are very few good reasons why a webmaster actually needs root .
Obviously in these instances , we can access the machine whenever we want , but as a matter of practice , we do n't unless monitoring pops and alert , or a customer submits a ticket .
If there 's going to be downtime , we try our damndest to work out a time with the customer , but some things ( eg , failed drives in an array ) constitute bringing the server down without prior customer contact. # 2 - Unmanaged hosting .
We build the box , install whatever OS you want on it , and then turn over root .
We do not monitor the box except for ping ( and if you firewall off ICMP , we 'll turn that off too ) , and we do n't touch the box without a specific request from the customer .
If the customer wants us to touch the box , it 's a very exorbitant hourly rate ( except for hardware failure , as the customer is renting the box from us , we 'll replace hardware at no charge , but any work on the server itself outside of that is billable ) .
For these boxes , we would obviously do the same thing with as the OP - we ask for the root password .
I 'm perfectly ok with providing our public key as well , but most folks would rather just turn over the root password and be done .
Occasionally , we do have to root these boxes - either because the customer has forgotten the root password , or because the customer has received a complaint of doing something illegal ( like running copyrighted torrents ) on the box , and we 're forced to investigate to cover our own year .
But for the most part , we do n't ever want to touch an unmanaged box if we can possibly avoid it .
Giving unskilled people root access who break their servers and then want us to fix it is not fun , hence the very large deterrent of the hourly rate .
It prevents folks from choosing an unmanaged server just to save a few bucks and then running to us every time something goes wrong. # 3 - Colocation .
You supply the hardware , or you can buy/rent hardware from us .
Generally folks will supply their own , and we just drop their network feed into their cage and they take it from there .
I can count on one hand the number of times I 've had to touch our colo hardware over the years , and if I 'm using the right finger , I can make a rude gesture while I 'm doing said counting .
Generally folks who choose a colo option know what they 're doing , and do n't need us , and only call if there 's an event that 's actually beyond their control , like a network issue.So honestly , I would take the OP with a grain of salt .
If he 's got his machine walled off so that only he can touch it on a regular basis , but he keeps opening tickets on a regular basis wanting to know exactly what happened , you 're not leaving the hosts tech staff with alot of options .
If you 're suffering outages , it 's a binary question as to who 's fault it is - it 's either the providers ( whether it 's network , core internal servers such as DNS , or the like ) or it 's your servers .
Presumably the host is going to know when it 's their problem , so if they 're asking to take a look at your server , that means the problem is probably actually your server , and not their network .
The OP either needs to lose the ego and give up the access or fix his own problems .
I suspect that if the OP were to change hosts , the tech staff would not be sorry to see him go</tokentext>
<sentencetext>First off, total disclosure - I work for a fairly well know web hosting provider as a system administrator.There's basically three plans we have.#1 - Managed hosting.
We build the box, we manage it, we give you an account to do stuff with.
We never give you root.
Ever. While I realize the thought of this is anathema to the majority of the slashdot crowd, the bottom line is that webmasters != sysadmin, and there are very few good reasons why a webmaster actually needs root.
Obviously in these instances, we can access the machine whenever we want, but as a matter of practice, we don't unless monitoring pops and alert, or a customer submits a ticket.
If there's going to be downtime, we try our damndest to work out a time with the customer, but some things (eg, failed drives in an array) constitute bringing the server down without prior customer contact.#2 - Unmanaged hosting.
We build the box, install whatever OS you want on it, and then turn over root.
We do not monitor the box except for ping (and if you firewall off ICMP, we'll turn that off too), and we don't touch the box without a specific request from the customer.
If the customer wants us to touch the box, it's a very exorbitant hourly rate (except for hardware failure, as the customer is renting the box from us, we'll replace hardware at no charge, but any work on the server itself outside of that is billable).
For these boxes, we would obviously do the same thing with as the OP - we ask for the root password.
I'm perfectly ok with providing our public key as well, but most folks would rather just turn over the root password and be done.
Occasionally, we do have to root these boxes - either because the customer has forgotten the root password, or because the customer has received a complaint of doing something illegal (like running copyrighted torrents) on the box, and we're forced to investigate to cover our own year.
But for the most part, we don't ever want to touch an unmanaged box if we can possibly avoid it.
Giving unskilled people root access who break their servers and then want us to fix it is not fun, hence the very large deterrent of the hourly rate.
It prevents folks from choosing an unmanaged server just to save a few bucks and then running to us every time something goes wrong.#3 - Colocation.
You supply the hardware, or you can buy/rent hardware from us.
Generally folks will supply their own, and we just drop their network feed into their cage and they take it from there.
I can count on one hand the number of times I've had to touch our colo hardware over the years, and if I'm using the right finger, I can make a rude gesture while I'm doing said counting.
Generally folks who choose a colo option know what they're doing, and don't need us, and only call if there's an event that's actually beyond their control, like a network issue.So honestly, I would take the OP with a grain of salt.
If he's got his machine walled off so that only he can touch it on a regular basis, but he keeps opening tickets on a regular basis wanting to know exactly what happened, you're not leaving the hosts tech staff with alot of options.
If you're suffering outages, it's a binary question as to who's fault it is - it's either the providers (whether it's network, core internal servers such as DNS, or the like) or it's your servers.
Presumably the host is going to know when it's their problem, so if they're asking to take a look at your server, that means the problem is probably actually your server, and not their network.
The OP either needs to lose the ego and give up the access or fix his own problems.
I suspect that if the OP were to change hosts, the tech staff would not be sorry to see him go</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560822</id>
	<title>Re:You're complicating things.</title>
	<author>dbIII</author>
	<datestamp>1261850220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Write it all up and we can use it as a case study to show why you should be the owner of the entire physical box.<br>As for the mail load problem (I doubt you've done this someone may get some benefit from this), I've seen one guy DOS himself with swatch after a major change that produced a lot of messages and then messages about the messages.<br>I'd say forget about wasting time and money with legal hassles - pay the small amount you need for access to get it temporarily fixed, send a request or two for a refund for that and vote with your feet with hardware you own somewhere else.</htmltext>
<tokenext>Write it all up and we can use it as a case study to show why you should be the owner of the entire physical box.As for the mail load problem ( I doubt you 've done this someone may get some benefit from this ) , I 've seen one guy DOS himself with swatch after a major change that produced a lot of messages and then messages about the messages.I 'd say forget about wasting time and money with legal hassles - pay the small amount you need for access to get it temporarily fixed , send a request or two for a refund for that and vote with your feet with hardware you own somewhere else .</tokentext>
<sentencetext>Write it all up and we can use it as a case study to show why you should be the owner of the entire physical box.As for the mail load problem (I doubt you've done this someone may get some benefit from this), I've seen one guy DOS himself with swatch after a major change that produced a lot of messages and then messages about the messages.I'd say forget about wasting time and money with legal hassles - pay the small amount you need for access to get it temporarily fixed, send a request or two for a refund for that and vote with your feet with hardware you own somewhere else.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557614</id>
	<title>Re:If they do this..</title>
	<author>clint999</author>
	<datestamp>1261859400000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><blockquote><div><p>"Highly intelligent people tend towards a sometimes unreasonable paranoia and sometimes make conclusions (i.e. my server was rooted to look at the logs) that are not exactly true."Shoot, even people of normal intelligence, or, equally surprising, people of limited intelligence, jump to idiotic conclusions.Either way, you're correct - if you ain't happy with the service, find another service...</p></div></blockquote></div>
	</htmltext>
<tokenext>" Highly intelligent people tend towards a sometimes unreasonable paranoia and sometimes make conclusions ( i.e .
my server was rooted to look at the logs ) that are not exactly true .
" Shoot , even people of normal intelligence , or , equally surprising , people of limited intelligence , jump to idiotic conclusions.Either way , you 're correct - if you ai n't happy with the service , find another service.. .</tokentext>
<sentencetext>"Highly intelligent people tend towards a sometimes unreasonable paranoia and sometimes make conclusions (i.e.
my server was rooted to look at the logs) that are not exactly true.
"Shoot, even people of normal intelligence, or, equally surprising, people of limited intelligence, jump to idiotic conclusions.Either way, you're correct - if you ain't happy with the service, find another service...
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558892</id>
	<title>Re:If they do this..</title>
	<author>shaitand</author>
	<datestamp>1261826160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Actually liability generally runs the other way. You are a service provider and enjoy common carrier and safe harbors provisions so long as you DON'T know what is running through your network.</p><p>If you access someone elses server you could be held liable for what it is serving as well as for the breach of the confidential data on the machine. For instance that server might hold credit card details, you could be held liable for identity theft.</p></htmltext>
<tokenext>Actually liability generally runs the other way .
You are a service provider and enjoy common carrier and safe harbors provisions so long as you DO N'T know what is running through your network.If you access someone elses server you could be held liable for what it is serving as well as for the breach of the confidential data on the machine .
For instance that server might hold credit card details , you could be held liable for identity theft .</tokentext>
<sentencetext>Actually liability generally runs the other way.
You are a service provider and enjoy common carrier and safe harbors provisions so long as you DON'T know what is running through your network.If you access someone elses server you could be held liable for what it is serving as well as for the breach of the confidential data on the machine.
For instance that server might hold credit card details, you could be held liable for identity theft.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556960</id>
	<title>They have physical access, so game over</title>
	<author>Junior J. Junior III</author>
	<datestamp>1261853580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Sue them.  And switch to a different company.</p></htmltext>
<tokenext>Sue them .
And switch to a different company .</tokentext>
<sentencetext>Sue them.
And switch to a different company.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30565480</id>
	<title>Re:you might be our customer</title>
	<author>Eil</author>
	<datestamp>1261907760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In that case, you are definitely getting the shaft and need to find another host.</p></htmltext>
<tokenext>In that case , you are definitely getting the shaft and need to find another host .</tokentext>
<sentencetext>In that case, you are definitely getting the shaft and need to find another host.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560130</id>
	<title>Virtual shared server with "Best Effort" SLA</title>
	<author>ittanmomen</author>
	<datestamp>1261840260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sound to me like the poster uses a virtual shared server, ie. The hosting company provides a virtual root environment, this would be an explanation why they can "root" the server, ie. just access the file system directly from the hypervisor.


I am sure this kind of service does not include uptime guarantees, it operates most likely under "Best Effort" promise. Which means they do not need to guarantee either uptime or availability. Their monitoring system and logs do not detect any error, so they want to check the posters systems logs - a reasonable request as they are trying to help him.

Monitoring is a difficult task - what to you measure, where is your sensor.  Was the outage on your own internet connection rather than on the server?

"Moments ago, there were three simultaneous outages while I was logged into the server working on some projects. " It sounds very suspicious, like  the admin interface causes interruption in the VM.  Something like this happened to my VMWare Servers totally unexplainable, but reproducably.</htmltext>
<tokenext>Sound to me like the poster uses a virtual shared server , ie .
The hosting company provides a virtual root environment , this would be an explanation why they can " root " the server , ie .
just access the file system directly from the hypervisor .
I am sure this kind of service does not include uptime guarantees , it operates most likely under " Best Effort " promise .
Which means they do not need to guarantee either uptime or availability .
Their monitoring system and logs do not detect any error , so they want to check the posters systems logs - a reasonable request as they are trying to help him .
Monitoring is a difficult task - what to you measure , where is your sensor .
Was the outage on your own internet connection rather than on the server ?
" Moments ago , there were three simultaneous outages while I was logged into the server working on some projects .
" It sounds very suspicious , like the admin interface causes interruption in the VM .
Something like this happened to my VMWare Servers totally unexplainable , but reproducably .</tokentext>
<sentencetext>Sound to me like the poster uses a virtual shared server, ie.
The hosting company provides a virtual root environment, this would be an explanation why they can "root" the server, ie.
just access the file system directly from the hypervisor.
I am sure this kind of service does not include uptime guarantees, it operates most likely under "Best Effort" promise.
Which means they do not need to guarantee either uptime or availability.
Their monitoring system and logs do not detect any error, so they want to check the posters systems logs - a reasonable request as they are trying to help him.
Monitoring is a difficult task - what to you measure, where is your sensor.
Was the outage on your own internet connection rather than on the server?
"Moments ago, there were three simultaneous outages while I was logged into the server working on some projects.
" It sounds very suspicious, like  the admin interface causes interruption in the VM.
Something like this happened to my VMWare Servers totally unexplainable, but reproducably.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557690</id>
	<title>Physical access trumps all</title>
	<author>Rix</author>
	<datestamp>1261859880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You cannot withhold anything from someone that has physical access to your machine. Anything they want to take, they can.</p><p>If you don't trust them with the root password, you shouldn't trust them with physical access.</p></htmltext>
<tokenext>You can not withhold anything from someone that has physical access to your machine .
Anything they want to take , they can.If you do n't trust them with the root password , you should n't trust them with physical access .</tokentext>
<sentencetext>You cannot withhold anything from someone that has physical access to your machine.
Anything they want to take, they can.If you don't trust them with the root password, you shouldn't trust them with physical access.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30563002</id>
	<title>Lawsuit?</title>
	<author>Anonymous</author>
	<datestamp>1261927800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Look at Echomail v American Express and IBM (2006) out of MA, and look at whether your jurisdiction would allow for you to file a replevin action to get at the data.</p></htmltext>
<tokenext>Look at Echomail v American Express and IBM ( 2006 ) out of MA , and look at whether your jurisdiction would allow for you to file a replevin action to get at the data .</tokentext>
<sentencetext>Look at Echomail v American Express and IBM (2006) out of MA, and look at whether your jurisdiction would allow for you to file a replevin action to get at the data.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562556</id>
	<title>Sorry, but are you stupid?</title>
	<author>RichiH</author>
	<datestamp>1261920720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Excuse the ad hominem, but WHAT THE FUCK?</p><p>The first time this happens, you verify the backups, get another box somewhere else, migrate services, cancel the old contract and file criminal charges, in this order. Optionally, cry as loud as you can about it.</p><p>Sure, the police might not do anything about it, but you need to try, at least.</p><p>If you log and monitor as much as you claim, I really do wonder why you did not realize this yourself...</p></htmltext>
<tokenext>Excuse the ad hominem , but WHAT THE FUCK ? The first time this happens , you verify the backups , get another box somewhere else , migrate services , cancel the old contract and file criminal charges , in this order .
Optionally , cry as loud as you can about it.Sure , the police might not do anything about it , but you need to try , at least.If you log and monitor as much as you claim , I really do wonder why you did not realize this yourself.. .</tokentext>
<sentencetext>Excuse the ad hominem, but WHAT THE FUCK?The first time this happens, you verify the backups, get another box somewhere else, migrate services, cancel the old contract and file criminal charges, in this order.
Optionally, cry as loud as you can about it.Sure, the police might not do anything about it, but you need to try, at least.If you log and monitor as much as you claim, I really do wonder why you did not realize this yourself...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388</id>
	<title>you might be our customer</title>
	<author>Anonymous</author>
	<datestamp>1261857240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Okay, since a lot of Slashdotters run their own servers rather than utilize the services of a web hosting company, let me provide some background info. I don't know whether the OP is one of our customers or not, but at the web hosting company I work for, there are two ways to host your server with us:</p><p>1. You can co-locate your hardware with us and purchase a unmanaged plan where the only support we offer is reboots and network troubleshooting. Everything else from the OS to web applications is your sole responsibility.</p><p>2. You can rent a server from us, which comes with full managed support, meaning the box is provisioned and configured by us, and our techs have full root access to your host in order to resolve any problems that come up. All services on the machine are monitored by Nagios, so we know (and react) within 5 minutes when a service stops responding.</p><p>You don't specify which hosting plan you have, but from your description of your problem, it sounds like you purchased #2. All of the things you describe are exactly what our technicians would do if we were charged with keeping a managed server online and a customer was making that task impossible to do. If a customer is asking us to fix a problem and is only making it worse or more difficult by virtue of their incompetence, we have been known to lock them out of their own server until the problem is fixed.</p><p>The bottom line is: <b>don't rent a managed server if you don't want managed service</b>. If you want full control over your hardware, you need to talk to the sales team and tell them that you want an unmanaged plan. The trade-off, of course, is that you have to deal with your own "WTF" problems from then on.</p></htmltext>
<tokenext>Okay , since a lot of Slashdotters run their own servers rather than utilize the services of a web hosting company , let me provide some background info .
I do n't know whether the OP is one of our customers or not , but at the web hosting company I work for , there are two ways to host your server with us : 1 .
You can co-locate your hardware with us and purchase a unmanaged plan where the only support we offer is reboots and network troubleshooting .
Everything else from the OS to web applications is your sole responsibility.2 .
You can rent a server from us , which comes with full managed support , meaning the box is provisioned and configured by us , and our techs have full root access to your host in order to resolve any problems that come up .
All services on the machine are monitored by Nagios , so we know ( and react ) within 5 minutes when a service stops responding.You do n't specify which hosting plan you have , but from your description of your problem , it sounds like you purchased # 2 .
All of the things you describe are exactly what our technicians would do if we were charged with keeping a managed server online and a customer was making that task impossible to do .
If a customer is asking us to fix a problem and is only making it worse or more difficult by virtue of their incompetence , we have been known to lock them out of their own server until the problem is fixed.The bottom line is : do n't rent a managed server if you do n't want managed service .
If you want full control over your hardware , you need to talk to the sales team and tell them that you want an unmanaged plan .
The trade-off , of course , is that you have to deal with your own " WTF " problems from then on .</tokentext>
<sentencetext>Okay, since a lot of Slashdotters run their own servers rather than utilize the services of a web hosting company, let me provide some background info.
I don't know whether the OP is one of our customers or not, but at the web hosting company I work for, there are two ways to host your server with us:1.
You can co-locate your hardware with us and purchase a unmanaged plan where the only support we offer is reboots and network troubleshooting.
Everything else from the OS to web applications is your sole responsibility.2.
You can rent a server from us, which comes with full managed support, meaning the box is provisioned and configured by us, and our techs have full root access to your host in order to resolve any problems that come up.
All services on the machine are monitored by Nagios, so we know (and react) within 5 minutes when a service stops responding.You don't specify which hosting plan you have, but from your description of your problem, it sounds like you purchased #2.
All of the things you describe are exactly what our technicians would do if we were charged with keeping a managed server online and a customer was making that task impossible to do.
If a customer is asking us to fix a problem and is only making it worse or more difficult by virtue of their incompetence, we have been known to lock them out of their own server until the problem is fixed.The bottom line is: don't rent a managed server if you don't want managed service.
If you want full control over your hardware, you need to talk to the sales team and tell them that you want an unmanaged plan.
The trade-off, of course, is that you have to deal with your own "WTF" problems from then on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558920</id>
	<title>The Rules of Security</title>
	<author>kantos</author>
	<datestamp>1261826280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Why am I the one posting this... (sighs) anyway this is all 20-20 hindsight but let it be a lesson to always follow the <a href="http://technet.microsoft.com/en-us/library/cc722487.aspx" title="microsoft.com" rel="nofollow">rules of security</a> [microsoft.com] (Yes it's on technet, yes MS should follow their own rules). Failure to do so will result in this in this case you failed on.</p><ul> <li>Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore</li><li>Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.</li></ul><p>Regardless, you should get your own hardware in a co-lo you've background checked and have references for. Once you've done that you should do what every respectable admin has been doing for years, turn off direct root access, Set up <a href="http://www.ibm.com/developerworks/library/l-keyc.html" title="ibm.com" rel="nofollow">Public Key Authentication</a> [ibm.com], and for the love of all that is secure turn off password auth for SSH. If you do that then any unauthorized access to your box is in violation of 18 U.S.C. 1030 and is punishable under the law.</p></htmltext>
<tokenext>Why am I the one posting this... ( sighs ) anyway this is all 20-20 hindsight but let it be a lesson to always follow the rules of security [ microsoft.com ] ( Yes it 's on technet , yes MS should follow their own rules ) .
Failure to do so will result in this in this case you failed on .
Law # 2 : If a bad guy can alter the operating system on your computer , it 's not your computer anymoreLaw # 3 : If a bad guy has unrestricted physical access to your computer , it 's not your computer anymore.Regardless , you should get your own hardware in a co-lo you 've background checked and have references for .
Once you 've done that you should do what every respectable admin has been doing for years , turn off direct root access , Set up Public Key Authentication [ ibm.com ] , and for the love of all that is secure turn off password auth for SSH .
If you do that then any unauthorized access to your box is in violation of 18 U.S.C .
1030 and is punishable under the law .</tokentext>
<sentencetext>Why am I the one posting this... (sighs) anyway this is all 20-20 hindsight but let it be a lesson to always follow the rules of security [microsoft.com] (Yes it's on technet, yes MS should follow their own rules).
Failure to do so will result in this in this case you failed on.
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymoreLaw #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.Regardless, you should get your own hardware in a co-lo you've background checked and have references for.
Once you've done that you should do what every respectable admin has been doing for years, turn off direct root access, Set up Public Key Authentication [ibm.com], and for the love of all that is secure turn off password auth for SSH.
If you do that then any unauthorized access to your box is in violation of 18 U.S.C.
1030 and is punishable under the law.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562036</id>
	<title>Re:Name and Shame</title>
	<author>Anonymous</author>
	<datestamp>1261911180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Given he's mentioned moving from Saavis to databank, it's more than likely LayeredTech.</p><p>They have a bad rep around for pulling big billing stunts as well. Within the period of a year they raised prices 3 times - of those only once was really justified and even *then* they didn't give everyone what they were promised (remote reboot access).</p><p>Thanks,</p></htmltext>
<tokenext>Given he 's mentioned moving from Saavis to databank , it 's more than likely LayeredTech.They have a bad rep around for pulling big billing stunts as well .
Within the period of a year they raised prices 3 times - of those only once was really justified and even * then * they did n't give everyone what they were promised ( remote reboot access ) .Thanks,</tokentext>
<sentencetext>Given he's mentioned moving from Saavis to databank, it's more than likely LayeredTech.They have a bad rep around for pulling big billing stunts as well.
Within the period of a year they raised prices 3 times - of those only once was really justified and even *then* they didn't give everyone what they were promised (remote reboot access).Thanks,</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559466</id>
	<title>Re:You're complicating things.</title>
	<author>slamb</author>
	<datestamp>1261831200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>For example, since this migration to Dallas, every other Sunday between 7:00am and 8:00am EST, my server's load goes over 100 as incoming connections spike over 700/sec., sendmail refuses connections due to the load, and the box seizes up.</p></div></blockquote><p>That's something you need to investigate. Are the 700 connections per second the cause of the slowdown, or a symptom? (Probably the cause, but you never know - the sender might have terribly aggressive retries.) Where are they coming from? You may simply be falling victim to an external DoS attack that started around the same time. It's possible the requests are coming from your provider (maybe a problem with a monitoring system), but you need to find that out.

</p><p>You wrote in another post:</p><blockquote><div><p>This IS an unmanaged plan. All [they] provide is ping and power, I do the rest. I manage the OS, the configuration and everything else.</p></div></blockquote><p>It's not their job to diagnose this sort of problem for you, then. Their response to your most recent ticket was unreasonable (and possibly even illegal), but your request wasn't reasonable either. If you need that kind of help, you'll have to pay for it. You'll be butting heads with your next provider as well otherwise.</p></div>
	</htmltext>
<tokenext>For example , since this migration to Dallas , every other Sunday between 7 : 00am and 8 : 00am EST , my server 's load goes over 100 as incoming connections spike over 700/sec. , sendmail refuses connections due to the load , and the box seizes up.That 's something you need to investigate .
Are the 700 connections per second the cause of the slowdown , or a symptom ?
( Probably the cause , but you never know - the sender might have terribly aggressive retries .
) Where are they coming from ?
You may simply be falling victim to an external DoS attack that started around the same time .
It 's possible the requests are coming from your provider ( maybe a problem with a monitoring system ) , but you need to find that out .
You wrote in another post : This IS an unmanaged plan .
All [ they ] provide is ping and power , I do the rest .
I manage the OS , the configuration and everything else.It 's not their job to diagnose this sort of problem for you , then .
Their response to your most recent ticket was unreasonable ( and possibly even illegal ) , but your request was n't reasonable either .
If you need that kind of help , you 'll have to pay for it .
You 'll be butting heads with your next provider as well otherwise .</tokentext>
<sentencetext>For example, since this migration to Dallas, every other Sunday between 7:00am and 8:00am EST, my server's load goes over 100 as incoming connections spike over 700/sec., sendmail refuses connections due to the load, and the box seizes up.That's something you need to investigate.
Are the 700 connections per second the cause of the slowdown, or a symptom?
(Probably the cause, but you never know - the sender might have terribly aggressive retries.
) Where are they coming from?
You may simply be falling victim to an external DoS attack that started around the same time.
It's possible the requests are coming from your provider (maybe a problem with a monitoring system), but you need to find that out.
You wrote in another post:This IS an unmanaged plan.
All [they] provide is ping and power, I do the rest.
I manage the OS, the configuration and everything else.It's not their job to diagnose this sort of problem for you, then.
Their response to your most recent ticket was unreasonable (and possibly even illegal), but your request wasn't reasonable either.
If you need that kind of help, you'll have to pay for it.
You'll be butting heads with your next provider as well otherwise.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562712</id>
	<title>Rooting the Box</title>
	<author>Anonymous</author>
	<datestamp>1261923960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work for a hosting provider and the way you reset the password is by booting from a utility CD that resets it.  There are most likely other similar options that allow you to see the root password.</p><p>While I understand this guys concern, how to you troubleshoot an issue without root access to the box.  Frequently customers assume that this was a network issue, when it was really something on their server that consumed all available resources that caused their server to stop responding to new requests.  I've lost count of the number of people who've complained about their performance only to find that it was their code or database connections that were never closed.  My suggestion is to create an account with root privileges, disable it, and only enable it when you require assistance.  There is no excuse for resenting a customer's password without their consent.  If a customer asks for help but doesn't provide credentials, we request them and take no action until they provide unless the server is actually down hard.</p></htmltext>
<tokenext>I work for a hosting provider and the way you reset the password is by booting from a utility CD that resets it .
There are most likely other similar options that allow you to see the root password.While I understand this guys concern , how to you troubleshoot an issue without root access to the box .
Frequently customers assume that this was a network issue , when it was really something on their server that consumed all available resources that caused their server to stop responding to new requests .
I 've lost count of the number of people who 've complained about their performance only to find that it was their code or database connections that were never closed .
My suggestion is to create an account with root privileges , disable it , and only enable it when you require assistance .
There is no excuse for resenting a customer 's password without their consent .
If a customer asks for help but does n't provide credentials , we request them and take no action until they provide unless the server is actually down hard .</tokentext>
<sentencetext>I work for a hosting provider and the way you reset the password is by booting from a utility CD that resets it.
There are most likely other similar options that allow you to see the root password.While I understand this guys concern, how to you troubleshoot an issue without root access to the box.
Frequently customers assume that this was a network issue, when it was really something on their server that consumed all available resources that caused their server to stop responding to new requests.
I've lost count of the number of people who've complained about their performance only to find that it was their code or database connections that were never closed.
My suggestion is to create an account with root privileges, disable it, and only enable it when you require assistance.
There is no excuse for resenting a customer's password without their consent.
If a customer asks for help but doesn't provide credentials, we request them and take no action until they provide unless the server is actually down hard.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557756</id>
	<title>create a temporary account - grant sudo access</title>
	<author>jimbalya</author>
	<datestamp>1261860480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you don't want to provide them with the root password, you could create a temporary user account that can sudo to root w/o the password.</p><p>
&nbsp;</p></htmltext>
<tokenext>If you do n't want to provide them with the root password , you could create a temporary user account that can sudo to root w/o the password .
 </tokentext>
<sentencetext>If you don't want to provide them with the root password, you could create a temporary user account that can sudo to root w/o the password.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556936</id>
	<title>Face palm</title>
	<author>buss\_error</author>
	<datestamp>1261853400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Among the many choices you have, you can install a remote monitoring/administration card.<br>But that's really using technology to solve the wrong problem. The problem is your ISP.<br>Fire your ISP. You already have two very good reasons for doing so. First, they<br>should simply ask for the logs, not demand entry into the system. Second, for taking<br>down your server, breaking into it (what if you had data on there you didn't want<br>unauthorized people to see?) without your express, positive, verified consent.</p><p>Using technology to solve a problem is a fine thing. However, the problem you are<br>reporting isn't technical.</p></htmltext>
<tokenext>Among the many choices you have , you can install a remote monitoring/administration card.But that 's really using technology to solve the wrong problem .
The problem is your ISP.Fire your ISP .
You already have two very good reasons for doing so .
First , theyshould simply ask for the logs , not demand entry into the system .
Second , for takingdown your server , breaking into it ( what if you had data on there you did n't wantunauthorized people to see ?
) without your express , positive , verified consent.Using technology to solve a problem is a fine thing .
However , the problem you arereporting is n't technical .</tokentext>
<sentencetext>Among the many choices you have, you can install a remote monitoring/administration card.But that's really using technology to solve the wrong problem.
The problem is your ISP.Fire your ISP.
You already have two very good reasons for doing so.
First, theyshould simply ask for the logs, not demand entry into the system.
Second, for takingdown your server, breaking into it (what if you had data on there you didn't wantunauthorized people to see?
) without your express, positive, verified consent.Using technology to solve a problem is a fine thing.
However, the problem you arereporting isn't technical.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30563330</id>
	<title>Re:</title>
	<author>clint999</author>
	<datestamp>1261931400000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><blockquote><div><p>I like your screen option, but there are legitimate reasons for a provider to have *some* access, unless you appreciate being down for additional time.  Then possibly being charged for what would normally be included as part of the service due to making it difficult on the provider to assist you when something does go wrong.

Personally if your going to go that paranoid your better off coloing with a local provider that you can physically visit 24/7 unescorted and secure your server behind a locked cabinet</p></div></blockquote></div>
	</htmltext>
<tokenext>I like your screen option , but there are legitimate reasons for a provider to have * some * access , unless you appreciate being down for additional time .
Then possibly being charged for what would normally be included as part of the service due to making it difficult on the provider to assist you when something does go wrong .
Personally if your going to go that paranoid your better off coloing with a local provider that you can physically visit 24/7 unescorted and secure your server behind a locked cabinet</tokentext>
<sentencetext>I like your screen option, but there are legitimate reasons for a provider to have *some* access, unless you appreciate being down for additional time.
Then possibly being charged for what would normally be included as part of the service due to making it difficult on the provider to assist you when something does go wrong.
Personally if your going to go that paranoid your better off coloing with a local provider that you can physically visit 24/7 unescorted and secure your server behind a locked cabinet
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560718</id>
	<title>Why is hacker still doing business with them?</title>
	<author>diablo-d3</author>
	<datestamp>1261848840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It seems like hes paying a lot for managed service and is getting angry when they try to manage him. Just go do business with <a href="http://rapidxen.net/" title="rapidxen.net" rel="nofollow">RapidXen</a> [rapidxen.net] or some other VPS/dedi provider that isn't a bunch of dicks.<br> <br>
Disclaimer: I am a RapidXen customer, and am quite happy with their service.</htmltext>
<tokenext>It seems like hes paying a lot for managed service and is getting angry when they try to manage him .
Just go do business with RapidXen [ rapidxen.net ] or some other VPS/dedi provider that is n't a bunch of dicks .
Disclaimer : I am a RapidXen customer , and am quite happy with their service .</tokentext>
<sentencetext>It seems like hes paying a lot for managed service and is getting angry when they try to manage him.
Just go do business with RapidXen [rapidxen.net] or some other VPS/dedi provider that isn't a bunch of dicks.
Disclaimer: I am a RapidXen customer, and am quite happy with their service.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30563092</id>
	<title>OpenBSD baby!</title>
	<author>Anonymous</author>
	<datestamp>1261928820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://geektechnique.org/projectlab/84/openbsd-encrypted-fileserver-howto</p></htmltext>
<tokenext>http : //geektechnique.org/projectlab/84/openbsd-encrypted-fileserver-howto</tokentext>
<sentencetext>http://geektechnique.org/projectlab/84/openbsd-encrypted-fileserver-howto</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557890</id>
	<title>Re:Tough question...</title>
	<author>iggymanz</author>
	<datestamp>1261818120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>silly question</p><p>the answer is, marry her.</p><p>if she doesn't stop turning tricks you can be her pimp and have double income!   bonus!</p></htmltext>
<tokenext>silly questionthe answer is , marry her.if she does n't stop turning tricks you can be her pimp and have double income !
bonus !</tokentext>
<sentencetext>silly questionthe answer is, marry her.if she doesn't stop turning tricks you can be her pimp and have double income!
bonus!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559698</id>
	<title>legal advise maybe?</title>
	<author>gearloos</author>
	<datestamp>1261834200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well, Id run from than fast anyway. Also if it's not in your agreement, might see a lawyer on them going into your server anyway.</htmltext>
<tokenext>Well , Id run from than fast anyway .
Also if it 's not in your agreement , might see a lawyer on them going into your server anyway .</tokentext>
<sentencetext>Well, Id run from than fast anyway.
Also if it's not in your agreement, might see a lawyer on them going into your server anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750</id>
	<title>If they do this..</title>
	<author>sopssa</author>
	<datestamp>1261851900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>.. just switch providers. I'm sure there are companies that treat you better.</p></htmltext>
<tokenext>.. just switch providers .
I 'm sure there are companies that treat you better .</tokentext>
<sentencetext>.. just switch providers.
I'm sure there are companies that treat you better.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557106</id>
	<title>Use Xen and run your apps in virtual machines</title>
	<author>xee</author>
	<datestamp>1261854900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Get a dedicated server running the latest centos or ubuntu server release.  Use Xen to run your various applications in dedicated virtual machines.  You can encrypt entire domains in a number of ways both internal and external.  A dedicated test domain can be set up for your hosting provider to access, etc.</p></htmltext>
<tokenext>Get a dedicated server running the latest centos or ubuntu server release .
Use Xen to run your various applications in dedicated virtual machines .
You can encrypt entire domains in a number of ways both internal and external .
A dedicated test domain can be set up for your hosting provider to access , etc .</tokentext>
<sentencetext>Get a dedicated server running the latest centos or ubuntu server release.
Use Xen to run your various applications in dedicated virtual machines.
You can encrypt entire domains in a number of ways both internal and external.
A dedicated test domain can be set up for your hosting provider to access, etc.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562970</id>
	<title>not rooted</title>
	<author>Anonymous</author>
	<datestamp>1261927440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You dont need to crack someones root password to get root access to a linux machine.  You simply boot it in single user mode unless you have a password on grub but hosting providers never set one on installs.</p></htmltext>
<tokenext>You dont need to crack someones root password to get root access to a linux machine .
You simply boot it in single user mode unless you have a password on grub but hosting providers never set one on installs .</tokentext>
<sentencetext>You dont need to crack someones root password to get root access to a linux machine.
You simply boot it in single user mode unless you have a password on grub but hosting providers never set one on installs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30563894</id>
	<title>Ugh, that sucks.</title>
	<author>stonecypher</author>
	<datestamp>1261937340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Basically no, you can't keep them out.  Get a better host, who respects your privacy.</p><p>There's a downside: most diagnostics aren't possible without root, and it's quite likely that most of your small outages they really don't know about.  If you seal them out of root, you're on your own up to the ethernet plug.</p><p>Some hosts will be happy to be told to GTFO the box, because it means less work for them.  Be aware that if you tell a host to GTFO the box, they're not likely to stand behind you if the FBI says you have kiddie porn or warez or so on.</p></htmltext>
<tokenext>Basically no , you ca n't keep them out .
Get a better host , who respects your privacy.There 's a downside : most diagnostics are n't possible without root , and it 's quite likely that most of your small outages they really do n't know about .
If you seal them out of root , you 're on your own up to the ethernet plug.Some hosts will be happy to be told to GTFO the box , because it means less work for them .
Be aware that if you tell a host to GTFO the box , they 're not likely to stand behind you if the FBI says you have kiddie porn or warez or so on .</tokentext>
<sentencetext>Basically no, you can't keep them out.
Get a better host, who respects your privacy.There's a downside: most diagnostics aren't possible without root, and it's quite likely that most of your small outages they really don't know about.
If you seal them out of root, you're on your own up to the ethernet plug.Some hosts will be happy to be told to GTFO the box, because it means less work for them.
Be aware that if you tell a host to GTFO the box, they're not likely to stand behind you if the FBI says you have kiddie porn or warez or so on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558022</id>
	<title>Know your real problems..</title>
	<author>tempest69</author>
	<datestamp>1261819320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>1.  From the top your not passing pertinent information, you have a website.  But you didnt if it's a Co-located machine.  Which is what my best guess is given the info.  <p>
2.  If they want to see the logs, it seems like a no brainer to make a logview account for that purpose.  unless you dont want them to see the logs.</p><p>
3.  They've violated your trust, it's time to move on.  Sue if they violated their contract, and you have enough proof/money.  </p><p>
4.  If your not ok with them looking at your logs, what level of extra outage are you willing to sacrifice for that privacy?</p><p>
Storm</p></htmltext>
<tokenext>1 .
From the top your not passing pertinent information , you have a website .
But you didnt if it 's a Co-located machine .
Which is what my best guess is given the info .
2. If they want to see the logs , it seems like a no brainer to make a logview account for that purpose .
unless you dont want them to see the logs .
3. They 've violated your trust , it 's time to move on .
Sue if they violated their contract , and you have enough proof/money .
4. If your not ok with them looking at your logs , what level of extra outage are you willing to sacrifice for that privacy ?
Storm</tokentext>
<sentencetext>1.
From the top your not passing pertinent information, you have a website.
But you didnt if it's a Co-located machine.
Which is what my best guess is given the info.
2.  If they want to see the logs, it seems like a no brainer to make a logview account for that purpose.
unless you dont want them to see the logs.
3.  They've violated your trust, it's time to move on.
Sue if they violated their contract, and you have enough proof/money.
4.  If your not ok with them looking at your logs, what level of extra outage are you willing to sacrifice for that privacy?
Storm</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558802</id>
	<title>WTF? That's like breaking into a loaned apartment.</title>
	<author>Anonymous</author>
	<datestamp>1261825440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Maybe the law is still a bit backwards, but you must agree that that&rsquo;s a very fitting analogy.</p><p>I&rsquo;d sue them, encrypt the hard disk (with booting a tiny system that then asks for the password via a ssh terminal connection), and move to another provider. If in any way possible all at the same time. ^^</p><p>WTF. Just seriously WTF.</p><p>You could even sue them for lost profits because of the server being down. Or for hacking into it, for &ldquo;rooting&rdquo; it. I bet a lawyer could come up with a package that would blast their sorry asses to the gamma quadrant and back. ^^</p></htmltext>
<tokenext>Maybe the law is still a bit backwards , but you must agree that that    s a very fitting analogy.I    d sue them , encrypt the hard disk ( with booting a tiny system that then asks for the password via a ssh terminal connection ) , and move to another provider .
If in any way possible all at the same time .
^ ^ WTF. Just seriously WTF.You could even sue them for lost profits because of the server being down .
Or for hacking into it , for    rooting    it .
I bet a lawyer could come up with a package that would blast their sorry asses to the gamma quadrant and back .
^ ^</tokentext>
<sentencetext>Maybe the law is still a bit backwards, but you must agree that that’s a very fitting analogy.I’d sue them, encrypt the hard disk (with booting a tiny system that then asks for the password via a ssh terminal connection), and move to another provider.
If in any way possible all at the same time.
^^WTF. Just seriously WTF.You could even sue them for lost profits because of the server being down.
Or for hacking into it, for “rooting” it.
I bet a lawyer could come up with a package that would blast their sorry asses to the gamma quadrant and back.
^^</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557494</id>
	<title>Re:If they do this..</title>
	<author>iphayd</author>
	<datestamp>1261858200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Your analogy is off. It's more like there is a pothole in your driveway, and your concrete contractor asks for your keys to make sure that it isn't your wheels.</p></htmltext>
<tokenext>Your analogy is off .
It 's more like there is a pothole in your driveway , and your concrete contractor asks for your keys to make sure that it is n't your wheels .</tokentext>
<sentencetext>Your analogy is off.
It's more like there is a pothole in your driveway, and your concrete contractor asks for your keys to make sure that it isn't your wheels.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556952</id>
	<title>The Planet</title>
	<author>Anonymous</author>
	<datestamp>1261853580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is SOP at The Planet - which hosts on the cheapest commodity hardware they can hack together.  MiniATX with Celeron procs, all stacked together on a bread rack.  The switches are zip-tied to the racks, as are the power strips.<br> <br>
My NDA has long since expired - I'm open to answering questions via email if anyone has them.</htmltext>
<tokenext>This is SOP at The Planet - which hosts on the cheapest commodity hardware they can hack together .
MiniATX with Celeron procs , all stacked together on a bread rack .
The switches are zip-tied to the racks , as are the power strips .
My NDA has long since expired - I 'm open to answering questions via email if anyone has them .</tokentext>
<sentencetext>This is SOP at The Planet - which hosts on the cheapest commodity hardware they can hack together.
MiniATX with Celeron procs, all stacked together on a bread rack.
The switches are zip-tied to the racks, as are the power strips.
My NDA has long since expired - I'm open to answering questions via email if anyone has them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560246</id>
	<title>Encrypt your root partition</title>
	<author>Anonymous</author>
	<datestamp>1261842060000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've almost finished writing a HOWTO for full disk encryption on a Linode.<br>It'll be on their wiki in a few days time.</p></htmltext>
<tokenext>I 've almost finished writing a HOWTO for full disk encryption on a Linode.It 'll be on their wiki in a few days time .</tokentext>
<sentencetext>I've almost finished writing a HOWTO for full disk encryption on a Linode.It'll be on their wiki in a few days time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559102</id>
	<title>Re:you might be our customer</title>
	<author>Anonymous</author>
	<datestamp>1261827840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Well it sounds like you and your service provider are having a misunderstanding there. You believe you have an unmanaged plan, they believe you don't. Maybe if you should start phone dialog on that point and be polite about it, you'll get somewhere without resorting to the seemingly immature antics of trying to kick them out.</p><p>You should realize that they're competent people if you're competent at interacting with them. They aren't the big evil system that you *would* want to keep out.</p></htmltext>
<tokenext>Well it sounds like you and your service provider are having a misunderstanding there .
You believe you have an unmanaged plan , they believe you do n't .
Maybe if you should start phone dialog on that point and be polite about it , you 'll get somewhere without resorting to the seemingly immature antics of trying to kick them out.You should realize that they 're competent people if you 're competent at interacting with them .
They are n't the big evil system that you * would * want to keep out .</tokentext>
<sentencetext>Well it sounds like you and your service provider are having a misunderstanding there.
You believe you have an unmanaged plan, they believe you don't.
Maybe if you should start phone dialog on that point and be polite about it, you'll get somewhere without resorting to the seemingly immature antics of trying to kick them out.You should realize that they're competent people if you're competent at interacting with them.
They aren't the big evil system that you *would* want to keep out.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559182</id>
	<title>install to different mount point + chroot</title>
	<author>pikine</author>
	<datestamp>1261828440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Both yum and deb based distributions have the ability to bootstrap the whole system under a mount point other than root. This is for the benefit of their installer, as you can imagine. Simply apt-get/yum install the one package you need, say apache httpd, and the package management figures out all the dependencies. After installation, you chroot to the mount point (don't forget to mount<nobr> <wbr></nobr>/proc and<nobr> <wbr></nobr>/sys there too) and run the service you want.

</p><p>Instructions on how to build Amazon EC2 AMI is very similar to this, so you might find that helpful.

</p><ul>
<li> <a href="http://ec2ubuntu.googlecode.com/svn/trunk/bin/ec2ubuntu-build-ami" title="googlecode.com">http://ec2ubuntu.googlecode.com/svn/trunk/bin/ec2ubuntu-build-ami</a> [googlecode.com] </li><li> <a href="http://docs.amazonwebservices.com/AmazonEC2/dg/2006-06-26/creating-an-ami.html#install-operating-system" title="amazonwebservices.com">http://docs.amazonwebservices.com/AmazonEC2/dg/2006-06-26/creating-an-ami.html#install-operating-system</a> [amazonwebservices.com] </li></ul><p>Of course, for the purpose of chroot, you don't need to install any new kernel. If you already know about cryptsetup and LUKS, you can then mount an encrypted disk image, install the packages, and chroot into it for the service to run.

</p><p>After saying all this, I think you really should switch provider, given how unhappy you are with them. Even if you manage to get the whole Slashdot to side with you, your provider will not likely change the way they do things.</p></htmltext>
<tokenext>Both yum and deb based distributions have the ability to bootstrap the whole system under a mount point other than root .
This is for the benefit of their installer , as you can imagine .
Simply apt-get/yum install the one package you need , say apache httpd , and the package management figures out all the dependencies .
After installation , you chroot to the mount point ( do n't forget to mount /proc and /sys there too ) and run the service you want .
Instructions on how to build Amazon EC2 AMI is very similar to this , so you might find that helpful .
http : //ec2ubuntu.googlecode.com/svn/trunk/bin/ec2ubuntu-build-ami [ googlecode.com ] http : //docs.amazonwebservices.com/AmazonEC2/dg/2006-06-26/creating-an-ami.html # install-operating-system [ amazonwebservices.com ] Of course , for the purpose of chroot , you do n't need to install any new kernel .
If you already know about cryptsetup and LUKS , you can then mount an encrypted disk image , install the packages , and chroot into it for the service to run .
After saying all this , I think you really should switch provider , given how unhappy you are with them .
Even if you manage to get the whole Slashdot to side with you , your provider will not likely change the way they do things .</tokentext>
<sentencetext>Both yum and deb based distributions have the ability to bootstrap the whole system under a mount point other than root.
This is for the benefit of their installer, as you can imagine.
Simply apt-get/yum install the one package you need, say apache httpd, and the package management figures out all the dependencies.
After installation, you chroot to the mount point (don't forget to mount /proc and /sys there too) and run the service you want.
Instructions on how to build Amazon EC2 AMI is very similar to this, so you might find that helpful.
http://ec2ubuntu.googlecode.com/svn/trunk/bin/ec2ubuntu-build-ami [googlecode.com]  http://docs.amazonwebservices.com/AmazonEC2/dg/2006-06-26/creating-an-ami.html#install-operating-system [amazonwebservices.com] Of course, for the purpose of chroot, you don't need to install any new kernel.
If you already know about cryptsetup and LUKS, you can then mount an encrypted disk image, install the packages, and chroot into it for the service to run.
After saying all this, I think you really should switch provider, given how unhappy you are with them.
Even if you manage to get the whole Slashdot to side with you, your provider will not likely change the way they do things.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559090</id>
	<title>Re:You're complicating things.</title>
	<author>raatti</author>
	<datestamp>1261827660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Sendmail has many issues and really if the switchport's errorcounter is 0 and this occuring, it could be rather something like this: <a href="http://ha.ckers.org/slowloris/" title="ckers.org" rel="nofollow">http://ha.ckers.org/slowloris/</a> [ckers.org] (only SMTP implentation this time).

Doubtful there is anything wrong with NIC, just need more firewalling.</htmltext>
<tokenext>Sendmail has many issues and really if the switchport 's errorcounter is 0 and this occuring , it could be rather something like this : http : //ha.ckers.org/slowloris/ [ ckers.org ] ( only SMTP implentation this time ) .
Doubtful there is anything wrong with NIC , just need more firewalling .</tokentext>
<sentencetext>Sendmail has many issues and really if the switchport's errorcounter is 0 and this occuring, it could be rather something like this: http://ha.ckers.org/slowloris/ [ckers.org] (only SMTP implentation this time).
Doubtful there is anything wrong with NIC, just need more firewalling.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556908</id>
	<title>ESXi</title>
	<author>Anonymous</author>
	<datestamp>1261853100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Run ESXi as the host OS and give all available resources to the VM.  It's nice, because when the VM crashes, I can still see what's on the console, rather than calling the NOC monkeys and trying to decipher what they're telling me is on the console.</p></htmltext>
<tokenext>Run ESXi as the host OS and give all available resources to the VM .
It 's nice , because when the VM crashes , I can still see what 's on the console , rather than calling the NOC monkeys and trying to decipher what they 're telling me is on the console .</tokentext>
<sentencetext>Run ESXi as the host OS and give all available resources to the VM.
It's nice, because when the VM crashes, I can still see what's on the console, rather than calling the NOC monkeys and trying to decipher what they're telling me is on the console.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559982</id>
	<title>Take it one step further...</title>
	<author>Anonymous</author>
	<datestamp>1261837980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Rootkit yourself and see what they are doing.  It is easy enough and if you really want to be sure that you know what is going on without physical access to the hardware, I think that it is the only way.  Read your contract first, but it should be perfectly legal.</p></htmltext>
<tokenext>Rootkit yourself and see what they are doing .
It is easy enough and if you really want to be sure that you know what is going on without physical access to the hardware , I think that it is the only way .
Read your contract first , but it should be perfectly legal .</tokentext>
<sentencetext>Rootkit yourself and see what they are doing.
It is easy enough and if you really want to be sure that you know what is going on without physical access to the hardware, I think that it is the only way.
Read your contract first, but it should be perfectly legal.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557558</id>
	<title>Re:If they do this..</title>
	<author>socsoc</author>
	<datestamp>1261858860000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>I definitely agree. The local staff at my colos are happy to do simple tasks while acting as my eyes and performing keyboard instructions on my behalf (if it's critical) or even simply exchanging a dvdr in a backup burner, otherwise they need to (and would) stay away.  But those are my boxes in a rack and any network outages could be confirmed by the datacenter's logging and equipment.

</p><p> I get the impression that OP doesn't have his own equipment in a rented rack, otherwise hardware would be solely on OP's shoulders.  If you are using their equipment, I don't feel that it's unreasonable to ask you for logs to diagnose, however they should have gone about it legitimately with you sharing it to them.

</p><p> Screw this paranoia about encryption, The Man isn't gonna come after your FOSS site and it just adds additional complexity that needs to be troubleshooted when things go south. If your sites are so heavily trafficked, buy your own box to eliminate one of the things you are blaming on the provider and move over to a provider who will not fuck with your box on a whim and respects you.</p></htmltext>
<tokenext>I definitely agree .
The local staff at my colos are happy to do simple tasks while acting as my eyes and performing keyboard instructions on my behalf ( if it 's critical ) or even simply exchanging a dvdr in a backup burner , otherwise they need to ( and would ) stay away .
But those are my boxes in a rack and any network outages could be confirmed by the datacenter 's logging and equipment .
I get the impression that OP does n't have his own equipment in a rented rack , otherwise hardware would be solely on OP 's shoulders .
If you are using their equipment , I do n't feel that it 's unreasonable to ask you for logs to diagnose , however they should have gone about it legitimately with you sharing it to them .
Screw this paranoia about encryption , The Man is n't gon na come after your FOSS site and it just adds additional complexity that needs to be troubleshooted when things go south .
If your sites are so heavily trafficked , buy your own box to eliminate one of the things you are blaming on the provider and move over to a provider who will not fuck with your box on a whim and respects you .</tokentext>
<sentencetext>I definitely agree.
The local staff at my colos are happy to do simple tasks while acting as my eyes and performing keyboard instructions on my behalf (if it's critical) or even simply exchanging a dvdr in a backup burner, otherwise they need to (and would) stay away.
But those are my boxes in a rack and any network outages could be confirmed by the datacenter's logging and equipment.
I get the impression that OP doesn't have his own equipment in a rented rack, otherwise hardware would be solely on OP's shoulders.
If you are using their equipment, I don't feel that it's unreasonable to ask you for logs to diagnose, however they should have gone about it legitimately with you sharing it to them.
Screw this paranoia about encryption, The Man isn't gonna come after your FOSS site and it just adds additional complexity that needs to be troubleshooted when things go south.
If your sites are so heavily trafficked, buy your own box to eliminate one of the things you are blaming on the provider and move over to a provider who will not fuck with your box on a whim and respects you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557204</id>
	<title>It sounds like...</title>
	<author>jimpop</author>
	<datestamp>1261855860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It sounds like you have a "Managed Server" type of plan with your hosting provider.   With a managed plan, a provider has some legal obligations (despite customer instructions) to maintain the host.   Go find an "Unmanaged" hosting provider, or colo your own equipment.</p></htmltext>
<tokenext>It sounds like you have a " Managed Server " type of plan with your hosting provider .
With a managed plan , a provider has some legal obligations ( despite customer instructions ) to maintain the host .
Go find an " Unmanaged " hosting provider , or colo your own equipment .</tokentext>
<sentencetext>It sounds like you have a "Managed Server" type of plan with your hosting provider.
With a managed plan, a provider has some legal obligations (despite customer instructions) to maintain the host.
Go find an "Unmanaged" hosting provider, or colo your own equipment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557624</id>
	<title>Re:If they do this..</title>
	<author>Hillview</author>
	<datestamp>1261859460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"tech support 101" might just be a monkey.  Almost literally.</p><p>If it's outsourced tech support, you're likely talking to somebody who was just hired away from Burger King, reading a script.   They're literally given a "conversation flowchart" for every customer- they don't actually know anything about your network or  your computers, but they do know what questions they're told to ask and what order to ask them in.</p><p>It's a callcenter job, more about customer service than technical skill.</p></htmltext>
<tokenext>" tech support 101 " might just be a monkey .
Almost literally.If it 's outsourced tech support , you 're likely talking to somebody who was just hired away from Burger King , reading a script .
They 're literally given a " conversation flowchart " for every customer- they do n't actually know anything about your network or your computers , but they do know what questions they 're told to ask and what order to ask them in.It 's a callcenter job , more about customer service than technical skill .</tokentext>
<sentencetext>"tech support 101" might just be a monkey.
Almost literally.If it's outsourced tech support, you're likely talking to somebody who was just hired away from Burger King, reading a script.
They're literally given a "conversation flowchart" for every customer- they don't actually know anything about your network or  your computers, but they do know what questions they're told to ask and what order to ask them in.It's a callcenter job, more about customer service than technical skill.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556824</id>
	<title>Re:If they do this..</title>
	<author>Anonymous</author>
	<datestamp>1261852500000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>I also agree.</p><p>No need for a provider to do this to you at all.</p><p>I use three different providers covering different parts of the world and none of them would dream of doing anything like that.</p><p>On the other hand if I *ask* them to help rescue me, they are happy to.</p><p>Rgds</p><p>Damon</p></htmltext>
<tokenext>I also agree.No need for a provider to do this to you at all.I use three different providers covering different parts of the world and none of them would dream of doing anything like that.On the other hand if I * ask * them to help rescue me , they are happy to.RgdsDamon</tokentext>
<sentencetext>I also agree.No need for a provider to do this to you at all.I use three different providers covering different parts of the world and none of them would dream of doing anything like that.On the other hand if I *ask* them to help rescue me, they are happy to.RgdsDamon</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894</id>
	<title>You're complicating things.</title>
	<author>casualsax3</author>
	<datestamp>1261852980000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>Switch providers.  Plenty offer remote reboot and serial console or KVM for both VMs or physical servers, which would allow you to go crazy with custom encrypted partitions etc.  At the end of the day though, someone somewhere at the hosting company is still going to be able to reboot your server into a rescue environment and reset the root password.  Go colocation if you're really that paranoid about it.
<p>
You also have zero chance with litigation, unless you've somehow gotten them to sign something saying they specifically won't muck around in your server.
</p><p>
I'd also like to know how you *know* it's a hardware or network issue outside of your server. How do you know it's not your NIC driver hanging up? Older e1000 drivers (super common card in the hosting industry) are quite flaky.  What research have you done outside of your internal monitoring?</p></htmltext>
<tokenext>Switch providers .
Plenty offer remote reboot and serial console or KVM for both VMs or physical servers , which would allow you to go crazy with custom encrypted partitions etc .
At the end of the day though , someone somewhere at the hosting company is still going to be able to reboot your server into a rescue environment and reset the root password .
Go colocation if you 're really that paranoid about it .
You also have zero chance with litigation , unless you 've somehow gotten them to sign something saying they specifically wo n't muck around in your server .
I 'd also like to know how you * know * it 's a hardware or network issue outside of your server .
How do you know it 's not your NIC driver hanging up ?
Older e1000 drivers ( super common card in the hosting industry ) are quite flaky .
What research have you done outside of your internal monitoring ?</tokentext>
<sentencetext>Switch providers.
Plenty offer remote reboot and serial console or KVM for both VMs or physical servers, which would allow you to go crazy with custom encrypted partitions etc.
At the end of the day though, someone somewhere at the hosting company is still going to be able to reboot your server into a rescue environment and reset the root password.
Go colocation if you're really that paranoid about it.
You also have zero chance with litigation, unless you've somehow gotten them to sign something saying they specifically won't muck around in your server.
I'd also like to know how you *know* it's a hardware or network issue outside of your server.
How do you know it's not your NIC driver hanging up?
Older e1000 drivers (super common card in the hosting industry) are quite flaky.
What research have you done outside of your internal monitoring?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558008</id>
	<title>MANDOS and LUKS encrypted LVM</title>
	<author>Anonymous</author>
	<datestamp>1261819260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://wiki.fukt.bsnet.se/wiki/Mandos   will solve the local rooting problem, you will need to run an encrypted root partition</p><p>LUKS seems to be good for that...</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; anon</p></htmltext>
<tokenext>http : //wiki.fukt.bsnet.se/wiki/Mandos will solve the local rooting problem , you will need to run an encrypted root partitionLUKS seems to be good for that.. .         anon</tokentext>
<sentencetext>http://wiki.fukt.bsnet.se/wiki/Mandos   will solve the local rooting problem, you will need to run an encrypted root partitionLUKS seems to be good for that...
        anon</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880</id>
	<title>Re:If they do this..</title>
	<author>Anonymous</author>
	<datestamp>1261852860000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>I might ask for more evidence that the provider actually rooted the server before pronouncing judgment. I'm not saying that the person posing the question is lying, but simply because I don't have enough evidence either way.</p><p>Highly intelligent people tend towards a sometimes unreasonable paranoia and sometimes make conclusions (i.e. my server was rooted to look at the logs) that are not exactly true.</p><p>That said, I don't know either way really. It could be argued one way or another. If I were a provider, I might even insist upon the ability to access systems running on my network simply because of liability concerns as the provider. I as the provider can't be allowing untoward activity on my network.</p><p>That all said, and without actually proclaiming judgment one way or another, in the end if you're not happy with your provider for any reason, whether reasonable or not, you should just leave them and find a new one.</p></htmltext>
<tokenext>I might ask for more evidence that the provider actually rooted the server before pronouncing judgment .
I 'm not saying that the person posing the question is lying , but simply because I do n't have enough evidence either way.Highly intelligent people tend towards a sometimes unreasonable paranoia and sometimes make conclusions ( i.e .
my server was rooted to look at the logs ) that are not exactly true.That said , I do n't know either way really .
It could be argued one way or another .
If I were a provider , I might even insist upon the ability to access systems running on my network simply because of liability concerns as the provider .
I as the provider ca n't be allowing untoward activity on my network.That all said , and without actually proclaiming judgment one way or another , in the end if you 're not happy with your provider for any reason , whether reasonable or not , you should just leave them and find a new one .</tokentext>
<sentencetext>I might ask for more evidence that the provider actually rooted the server before pronouncing judgment.
I'm not saying that the person posing the question is lying, but simply because I don't have enough evidence either way.Highly intelligent people tend towards a sometimes unreasonable paranoia and sometimes make conclusions (i.e.
my server was rooted to look at the logs) that are not exactly true.That said, I don't know either way really.
It could be argued one way or another.
If I were a provider, I might even insist upon the ability to access systems running on my network simply because of liability concerns as the provider.
I as the provider can't be allowing untoward activity on my network.That all said, and without actually proclaiming judgment one way or another, in the end if you're not happy with your provider for any reason, whether reasonable or not, you should just leave them and find a new one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557896</id>
	<title>Re:you might be our customer</title>
	<author>rgigger</author>
	<datestamp>1261818180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I can understand what you are saying here but if you are renting a whole server, and not just sharing one with other customers, then shouldn't your provider limit their support to what you ask for?  If you say you have a problem, and you aren't willing to give them the info then shouldn't they say, "sorry we cant' fix your problem without more info" before you do a hard shutdown on their box and start snooping around?  I guess this could create some SLA issues, but it should be spelled out in the SLA that if they don't give you access then they can't guarantee uptime.</p><p>Under these circumstances your company would seriously break in and start snooping around?</p><p>In my mind this is analogous to calling your landlord with a leaky faucet but then not letting him in the house when he gets there.  Your landlord keeps a key to the place, but he can't go in without your permission.  If you want the faucet fixed and you don't give him permission to come in there you are out of luck on the faucet, but that doesn't give him the right to sneak in when you aren't home, lock you out of your own house, and go to town on your plumbing.</p><p>Also if this guy is telling the truth he isn't paying for any sort of management at all. (See his response to parent)</p></htmltext>
<tokenext>I can understand what you are saying here but if you are renting a whole server , and not just sharing one with other customers , then should n't your provider limit their support to what you ask for ?
If you say you have a problem , and you are n't willing to give them the info then should n't they say , " sorry we cant ' fix your problem without more info " before you do a hard shutdown on their box and start snooping around ?
I guess this could create some SLA issues , but it should be spelled out in the SLA that if they do n't give you access then they ca n't guarantee uptime.Under these circumstances your company would seriously break in and start snooping around ? In my mind this is analogous to calling your landlord with a leaky faucet but then not letting him in the house when he gets there .
Your landlord keeps a key to the place , but he ca n't go in without your permission .
If you want the faucet fixed and you do n't give him permission to come in there you are out of luck on the faucet , but that does n't give him the right to sneak in when you are n't home , lock you out of your own house , and go to town on your plumbing.Also if this guy is telling the truth he is n't paying for any sort of management at all .
( See his response to parent )</tokentext>
<sentencetext>I can understand what you are saying here but if you are renting a whole server, and not just sharing one with other customers, then shouldn't your provider limit their support to what you ask for?
If you say you have a problem, and you aren't willing to give them the info then shouldn't they say, "sorry we cant' fix your problem without more info" before you do a hard shutdown on their box and start snooping around?
I guess this could create some SLA issues, but it should be spelled out in the SLA that if they don't give you access then they can't guarantee uptime.Under these circumstances your company would seriously break in and start snooping around?In my mind this is analogous to calling your landlord with a leaky faucet but then not letting him in the house when he gets there.
Your landlord keeps a key to the place, but he can't go in without your permission.
If you want the faucet fixed and you don't give him permission to come in there you are out of luck on the faucet, but that doesn't give him the right to sneak in when you aren't home, lock you out of your own house, and go to town on your plumbing.Also if this guy is telling the truth he isn't paying for any sort of management at all.
(See his response to parent)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557374</id>
	<title>Other possible reason</title>
	<author>fireheadca</author>
	<datestamp>1261857180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Perhaps you were rooted by someone else and your service provider is trying to help you<br>figure this out.<br><br>If there was an outage on their side, it might be quite obvious. Maybe you need to ask more<br>questions and work with them to solve your problem.<br><br>---<br><br>Happy Festivus</htmltext>
<tokenext>Perhaps you were rooted by someone else and your service provider is trying to help youfigure this out.If there was an outage on their side , it might be quite obvious .
Maybe you need to ask morequestions and work with them to solve your problem.---Happy Festivus</tokentext>
<sentencetext>Perhaps you were rooted by someone else and your service provider is trying to help youfigure this out.If there was an outage on their side, it might be quite obvious.
Maybe you need to ask morequestions and work with them to solve your problem.---Happy Festivus</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558340</id>
	<title>Umm a hosted service?</title>
	<author>nurb432</author>
	<datestamp>1261821840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Aren't most virtual now anyway ( jails, etc ) and you are 'rooted' by the nature of how things work? Its THEIR hardware, their datacenter remember... ( unless you have a special relationship and you bought your own box )</p><p>If you don't like the way things are done, change providers or host it yourself.</p></htmltext>
<tokenext>Are n't most virtual now anyway ( jails , etc ) and you are 'rooted ' by the nature of how things work ?
Its THEIR hardware , their datacenter remember... ( unless you have a special relationship and you bought your own box ) If you do n't like the way things are done , change providers or host it yourself .</tokentext>
<sentencetext>Aren't most virtual now anyway ( jails, etc ) and you are 'rooted' by the nature of how things work?
Its THEIR hardware, their datacenter remember... ( unless you have a special relationship and you bought your own box )If you don't like the way things are done, change providers or host it yourself.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557634</id>
	<title>Re:If they do this..</title>
	<author>jmorris42</author>
	<datestamp>1261859460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; It seems to me that if a person can't fix a problem on their own, and that person then asks for help<br>&gt; fixing the problem, they need to give up some control to the person they have asked for help from.</p><p>Close but still not quite the root of the problem here.  It is a common one, a mismatch between responsibility and authority.  The guy was demanding the hosting provider assume responsibility beyond the authority he was willing to give them.  In the end the hosting provider claimed the matching authority to the responsibility the customer was holding them to and all hell broke loose.  They should have simply closed his trouble ticket as CANTFIX when he refused them access to the information they needed to work on his problem and let him leave in a snit.  A troublemaker like this customer would have been equally pissed off but the hosting provider would have gone into court (where this will almost certainly end up) with a rock solid case.</p></htmltext>
<tokenext>&gt; It seems to me that if a person ca n't fix a problem on their own , and that person then asks for help &gt; fixing the problem , they need to give up some control to the person they have asked for help from.Close but still not quite the root of the problem here .
It is a common one , a mismatch between responsibility and authority .
The guy was demanding the hosting provider assume responsibility beyond the authority he was willing to give them .
In the end the hosting provider claimed the matching authority to the responsibility the customer was holding them to and all hell broke loose .
They should have simply closed his trouble ticket as CANTFIX when he refused them access to the information they needed to work on his problem and let him leave in a snit .
A troublemaker like this customer would have been equally pissed off but the hosting provider would have gone into court ( where this will almost certainly end up ) with a rock solid case .</tokentext>
<sentencetext>&gt; It seems to me that if a person can't fix a problem on their own, and that person then asks for help&gt; fixing the problem, they need to give up some control to the person they have asked for help from.Close but still not quite the root of the problem here.
It is a common one, a mismatch between responsibility and authority.
The guy was demanding the hosting provider assume responsibility beyond the authority he was willing to give them.
In the end the hosting provider claimed the matching authority to the responsibility the customer was holding them to and all hell broke loose.
They should have simply closed his trouble ticket as CANTFIX when he refused them access to the information they needed to work on his problem and let him leave in a snit.
A troublemaker like this customer would have been equally pissed off but the hosting provider would have gone into court (where this will almost certainly end up) with a rock solid case.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562404</id>
	<title>Re:you might be our customer</title>
	<author>Anonymous</author>
	<datestamp>1261917900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><blockquote><div><p> <em>"If you want full control over your hardware, you need to talk to the sales team and tell them that you want an unmanaged plan. The trade-off, of course, is that you have to deal with your own "WTF" problems from then on."</em> </p></div></blockquote><p>This <em>IS</em> an unmanaged plan. All the provide is ping and power, I do the rest. I manage the OS, the configuration and everything else. This is not VPS, I lease a physical server, and they don't touch it.</p></div><p>You surely mean by that " All the provide is ping and power <em> and hardware </em>", which mean they own the box.  In that regard, <em>You </em> are most likely breaching your agreement with the provider.  A WTF? tickets will always be blamed on the hardware in a dedicated server place if the network logs show no anomaly.  You did mention your load went above 100.  That would qualify as a normal outage caused by too much traffic.  If you insist, they'll swap the server ( the chassis change )  to make you happy.  If you continue, they'll change your DC location ( the DC change ) to attempt to please you.</p><p>All I can see here is the provider attempting to cope with you.</p><p>Although I will agree they should juste have reseted your pass and given you access.</p></div>
	</htmltext>
<tokenext>" If you want full control over your hardware , you need to talk to the sales team and tell them that you want an unmanaged plan .
The trade-off , of course , is that you have to deal with your own " WTF " problems from then on .
" This IS an unmanaged plan .
All the provide is ping and power , I do the rest .
I manage the OS , the configuration and everything else .
This is not VPS , I lease a physical server , and they do n't touch it.You surely mean by that " All the provide is ping and power and hardware " , which mean they own the box .
In that regard , You are most likely breaching your agreement with the provider .
A WTF ?
tickets will always be blamed on the hardware in a dedicated server place if the network logs show no anomaly .
You did mention your load went above 100 .
That would qualify as a normal outage caused by too much traffic .
If you insist , they 'll swap the server ( the chassis change ) to make you happy .
If you continue , they 'll change your DC location ( the DC change ) to attempt to please you.All I can see here is the provider attempting to cope with you.Although I will agree they should juste have reseted your pass and given you access .</tokentext>
<sentencetext> "If you want full control over your hardware, you need to talk to the sales team and tell them that you want an unmanaged plan.
The trade-off, of course, is that you have to deal with your own "WTF" problems from then on.
" This IS an unmanaged plan.
All the provide is ping and power, I do the rest.
I manage the OS, the configuration and everything else.
This is not VPS, I lease a physical server, and they don't touch it.You surely mean by that " All the provide is ping and power  and hardware ", which mean they own the box.
In that regard, You  are most likely breaching your agreement with the provider.
A WTF?
tickets will always be blamed on the hardware in a dedicated server place if the network logs show no anomaly.
You did mention your load went above 100.
That would qualify as a normal outage caused by too much traffic.
If you insist, they'll swap the server ( the chassis change )  to make you happy.
If you continue, they'll change your DC location ( the DC change ) to attempt to please you.All I can see here is the provider attempting to cope with you.Although I will agree they should juste have reseted your pass and given you access.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557168</id>
	<title>Re:rooted? What does this word mean?</title>
	<author>http</author>
	<datestamp>1261855500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you have physical access to the machine, it's usually not hard to boot the machine into a state where there is a root shell running on the console.</htmltext>
<tokenext>If you have physical access to the machine , it 's usually not hard to boot the machine into a state where there is a root shell running on the console .</tokentext>
<sentencetext>If you have physical access to the machine, it's usually not hard to boot the machine into a state where there is a root shell running on the console.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556950</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557926</id>
	<title>Send them the logs as an email attachment.</title>
	<author>crovira</author>
	<datestamp>1261818480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Reply that you have security and NDA agreements that prevent you from giving them root access; then shovel copies of the logs out to them.</p></htmltext>
<tokenext>Reply that you have security and NDA agreements that prevent you from giving them root access ; then shovel copies of the logs out to them .</tokentext>
<sentencetext>Reply that you have security and NDA agreements that prevent you from giving them root access; then shovel copies of the logs out to them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006</id>
	<title>Tough question...</title>
	<author>Anonymous</author>
	<datestamp>1261854000000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>"How do I turn a whore into a housewife?"</p><p>Some things are only solved by replacment.</p></htmltext>
<tokenext>" How do I turn a whore into a housewife ?
" Some things are only solved by replacment .</tokentext>
<sentencetext>"How do I turn a whore into a housewife?
"Some things are only solved by replacment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559006</id>
	<title>Re:you might be our customer</title>
	<author>Anonymous</author>
	<datestamp>1261826940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Then their activities are illegal. Period.</p><p>Unfortunately, the quickest, cheapest way to solve the problem is to move on...</p><p>I've worked with losers like this before and no matter what you do they will deny, deny, deny.</p><p>Dump 'em.</p></htmltext>
<tokenext>Then their activities are illegal .
Period.Unfortunately , the quickest , cheapest way to solve the problem is to move on...I 've worked with losers like this before and no matter what you do they will deny , deny , deny.Dump 'em .</tokentext>
<sentencetext>Then their activities are illegal.
Period.Unfortunately, the quickest, cheapest way to solve the problem is to move on...I've worked with losers like this before and no matter what you do they will deny, deny, deny.Dump 'em.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557472</id>
	<title>Prevent Physical Access</title>
	<author>davidisonslashdot</author>
	<datestamp>1261858020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There are two ways that I can think of to prevent this.
1) Take a bike lock and wrap it around your server, chaining it closed and to everything nearby. They won't be able to root it easily, because the drive is locked in.
2) Go to the datacenter and pick up your server. Hide it in another companies racks, somewhere inconspicuous, and hope they don't follow any wires.</htmltext>
<tokenext>There are two ways that I can think of to prevent this .
1 ) Take a bike lock and wrap it around your server , chaining it closed and to everything nearby .
They wo n't be able to root it easily , because the drive is locked in .
2 ) Go to the datacenter and pick up your server .
Hide it in another companies racks , somewhere inconspicuous , and hope they do n't follow any wires .</tokentext>
<sentencetext>There are two ways that I can think of to prevent this.
1) Take a bike lock and wrap it around your server, chaining it closed and to everything nearby.
They won't be able to root it easily, because the drive is locked in.
2) Go to the datacenter and pick up your server.
Hide it in another companies racks, somewhere inconspicuous, and hope they don't follow any wires.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557098</id>
	<title>VM works best</title>
	<author>whoelse42</author>
	<datestamp>1261854840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I run several systems using vmware or one of the alternatives; all the guest OSes run encrypted partitions (requiring password to boot).  Generally, it makes it difficult even with physical access to gain access to the files.  Similarly, I prefer Truecrypt on Windows (* cringe *) machines.

In either case, all the machine's issue/login screen clearly state access to the machines are restricted to the rightful owner and any other access is a violation.  I've never had a problem with any colo facility before; while I've been asked on various occasions for the root password, I've provided the vm server's root password once (when a hardware / power supply failure occurred).  Obviously, the password was changed as soon as the boot occurred and I compared md5 hashes of all files on disk (for trojans).  Whenever outages occurred, I'd bz2 a few log files and send them over; I've received valid responses such as this failed or that failed or "we pulled the wrong cord".  However, I've also received lies such as "our accountant didn't send uunet their check this month" but then they've come clean.  However, never did they bring down a working machine to mess with it.

My advise, regardless of what you choose for file encryption, I'd suggest you immediately leave that 4th rate provider.</htmltext>
<tokenext>I run several systems using vmware or one of the alternatives ; all the guest OSes run encrypted partitions ( requiring password to boot ) .
Generally , it makes it difficult even with physical access to gain access to the files .
Similarly , I prefer Truecrypt on Windows ( * cringe * ) machines .
In either case , all the machine 's issue/login screen clearly state access to the machines are restricted to the rightful owner and any other access is a violation .
I 've never had a problem with any colo facility before ; while I 've been asked on various occasions for the root password , I 've provided the vm server 's root password once ( when a hardware / power supply failure occurred ) .
Obviously , the password was changed as soon as the boot occurred and I compared md5 hashes of all files on disk ( for trojans ) .
Whenever outages occurred , I 'd bz2 a few log files and send them over ; I 've received valid responses such as this failed or that failed or " we pulled the wrong cord " .
However , I 've also received lies such as " our accountant did n't send uunet their check this month " but then they 've come clean .
However , never did they bring down a working machine to mess with it .
My advise , regardless of what you choose for file encryption , I 'd suggest you immediately leave that 4th rate provider .</tokentext>
<sentencetext>I run several systems using vmware or one of the alternatives; all the guest OSes run encrypted partitions (requiring password to boot).
Generally, it makes it difficult even with physical access to gain access to the files.
Similarly, I prefer Truecrypt on Windows (* cringe *) machines.
In either case, all the machine's issue/login screen clearly state access to the machines are restricted to the rightful owner and any other access is a violation.
I've never had a problem with any colo facility before; while I've been asked on various occasions for the root password, I've provided the vm server's root password once (when a hardware / power supply failure occurred).
Obviously, the password was changed as soon as the boot occurred and I compared md5 hashes of all files on disk (for trojans).
Whenever outages occurred, I'd bz2 a few log files and send them over; I've received valid responses such as this failed or that failed or "we pulled the wrong cord".
However, I've also received lies such as "our accountant didn't send uunet their check this month" but then they've come clean.
However, never did they bring down a working machine to mess with it.
My advise, regardless of what you choose for file encryption, I'd suggest you immediately leave that 4th rate provider.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557946</id>
	<title>Send them an angry letter via certified mail</title>
	<author>mysidia</author>
	<datestamp>1261818600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
Be prepared to switch providers and file criminal charges against them under the Computer Fraud and Abuse act.
</p><p>
As for mitigating the chance of root compromise:
</p><ul>
  <li>Use a server with a remote SP, eg iLO, DRAC, that has virtual serial port</li><li>Enable login via serial port</li><li>In BSD: Mark Console as insecure in<nobr> <wbr></nobr>/etc/ttys</li><li>Set a BIOS password to be required for configuration changes.  This will be a fairly strong deterrant if your server stores BIOS info in NVRAM.  Specialized knowledge will be required of your specific server hardware to jumper the right pin for BIOS password bypass</li><li> Set Hard drives FIRST in the boot order, so the system will not boot from removable media.
  </li><li>
    Set a bootloader password, e.g. for Linux systems, set a grub password,  that will be required to change OS boot options.
  </li><li>
      Enable hard drive encryption.  E.g. on a clean install of OSes such as Fedora, you will be provided an option to encrypt your boot drive.
  </li><li>
      The downside of HDD encryption is: if a password is required to start the system, then it will be down after every reboot/power cycle, until you key in your password.
The use of iLO, DRAC, etc, remove KVM over IP to your server, or remote serial port (if you select serial), allows you to enter the password remotely.</li>

</ul></htmltext>
<tokenext>Be prepared to switch providers and file criminal charges against them under the Computer Fraud and Abuse act .
As for mitigating the chance of root compromise : Use a server with a remote SP , eg iLO , DRAC , that has virtual serial portEnable login via serial portIn BSD : Mark Console as insecure in /etc/ttysSet a BIOS password to be required for configuration changes .
This will be a fairly strong deterrant if your server stores BIOS info in NVRAM .
Specialized knowledge will be required of your specific server hardware to jumper the right pin for BIOS password bypass Set Hard drives FIRST in the boot order , so the system will not boot from removable media .
Set a bootloader password , e.g .
for Linux systems , set a grub password , that will be required to change OS boot options .
Enable hard drive encryption .
E.g. on a clean install of OSes such as Fedora , you will be provided an option to encrypt your boot drive .
The downside of HDD encryption is : if a password is required to start the system , then it will be down after every reboot/power cycle , until you key in your password .
The use of iLO , DRAC , etc , remove KVM over IP to your server , or remote serial port ( if you select serial ) , allows you to enter the password remotely .</tokentext>
<sentencetext>
Be prepared to switch providers and file criminal charges against them under the Computer Fraud and Abuse act.
As for mitigating the chance of root compromise:

  Use a server with a remote SP, eg iLO, DRAC, that has virtual serial portEnable login via serial portIn BSD: Mark Console as insecure in /etc/ttysSet a BIOS password to be required for configuration changes.
This will be a fairly strong deterrant if your server stores BIOS info in NVRAM.
Specialized knowledge will be required of your specific server hardware to jumper the right pin for BIOS password bypass Set Hard drives FIRST in the boot order, so the system will not boot from removable media.
Set a bootloader password, e.g.
for Linux systems, set a grub password,  that will be required to change OS boot options.
Enable hard drive encryption.
E.g. on a clean install of OSes such as Fedora, you will be provided an option to encrypt your boot drive.
The downside of HDD encryption is: if a password is required to start the system, then it will be down after every reboot/power cycle, until you key in your password.
The use of iLO, DRAC, etc, remove KVM over IP to your server, or remote serial port (if you select serial), allows you to enter the password remotely.

</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557016</id>
	<title>So why is it crashing?</title>
	<author>Animats</author>
	<datestamp>1261854060000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>
The logs should tell you why the machine crashed.
</p><p>
How busy was the server?
</p><p>
There's an ongoing Linux problem with crashing when a program needs more memory, the file cache is using all available memory, and a locking problem prevents paging out a file.  Search for <i>"prune\_one\_dentry" oops</i> (about 4000 hits in Google, from 2002 to 2009).  Despite years of patches, this is usually fixed in practice by throwing more RAM at the server. This failure is likely to happen when very large files are open and in use (as with a busy database) and programs are being launched at a high rate (as on an server).</p></htmltext>
<tokenext>The logs should tell you why the machine crashed .
How busy was the server ?
There 's an ongoing Linux problem with crashing when a program needs more memory , the file cache is using all available memory , and a locking problem prevents paging out a file .
Search for " prune \ _one \ _dentry " oops ( about 4000 hits in Google , from 2002 to 2009 ) .
Despite years of patches , this is usually fixed in practice by throwing more RAM at the server .
This failure is likely to happen when very large files are open and in use ( as with a busy database ) and programs are being launched at a high rate ( as on an server ) .</tokentext>
<sentencetext>
The logs should tell you why the machine crashed.
How busy was the server?
There's an ongoing Linux problem with crashing when a program needs more memory, the file cache is using all available memory, and a locking problem prevents paging out a file.
Search for "prune\_one\_dentry" oops (about 4000 hits in Google, from 2002 to 2009).
Despite years of patches, this is usually fixed in practice by throwing more RAM at the server.
This failure is likely to happen when very large files are open and in use (as with a busy database) and programs are being launched at a high rate (as on an server).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561046</id>
	<title>Re:If they do this..</title>
	<author>sydneyfong</author>
	<datestamp>1261854180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't think selective enforcement of the law is grounds for litigation. It might be grounds for launching a lawsuit for discrimination (race, gender, etc) or perhaps a more general judicial review lawsuit according to constitutional/administrative law, but selective enforcement is not one of them.</p><p>And it's ridiculously hard to prove selective enforcement, they can always make up reasons, and you need lots of statistics to really catch them.</p></htmltext>
<tokenext>I do n't think selective enforcement of the law is grounds for litigation .
It might be grounds for launching a lawsuit for discrimination ( race , gender , etc ) or perhaps a more general judicial review lawsuit according to constitutional/administrative law , but selective enforcement is not one of them.And it 's ridiculously hard to prove selective enforcement , they can always make up reasons , and you need lots of statistics to really catch them .</tokentext>
<sentencetext>I don't think selective enforcement of the law is grounds for litigation.
It might be grounds for launching a lawsuit for discrimination (race, gender, etc) or perhaps a more general judicial review lawsuit according to constitutional/administrative law, but selective enforcement is not one of them.And it's ridiculously hard to prove selective enforcement, they can always make up reasons, and you need lots of statistics to really catch them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559770</id>
	<title>Use SELinux</title>
	<author>UnderCoverPenguin</author>
	<datestamp>1261835100000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Enable SELinux in your server. Then disallow root from doing anything but looking at the logs. (Also, create a new, suitably enpowered, account for running your server). Then they can have root access all they want and not be able to mess with your server.</p></htmltext>
<tokenext>Enable SELinux in your server .
Then disallow root from doing anything but looking at the logs .
( Also , create a new , suitably enpowered , account for running your server ) .
Then they can have root access all they want and not be able to mess with your server .</tokentext>
<sentencetext>Enable SELinux in your server.
Then disallow root from doing anything but looking at the logs.
(Also, create a new, suitably enpowered, account for running your server).
Then they can have root access all they want and not be able to mess with your server.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558222</id>
	<title>Whores sell pussy to many. Housewives only to one.</title>
	<author>Anonymous</author>
	<datestamp>1261820640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>So the obvious answer is to get her to accept the exclusive offer.</htmltext>
<tokenext>So the obvious answer is to get her to accept the exclusive offer .</tokentext>
<sentencetext>So the obvious answer is to get her to accept the exclusive offer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559012</id>
	<title>Re:Name and Shame</title>
	<author>Anonymous</author>
	<datestamp>1261827060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I second with checking with local ISPs and see if they have something that offers similar.  TWC where I live has business cable access and offers static IPs.  The cost is more than consumer level stuff, but not so expensive that it isn't affordable.  In fact, I'm sure it probably compares in price to coloc fees, if not cheaper.  Some ISPs also doesn't seem to bill on bandwidth used, so this might be a positive consideration.</p><p>I don't know your (the OP) situation, but it might be a better alternative.</p></htmltext>
<tokenext>I second with checking with local ISPs and see if they have something that offers similar .
TWC where I live has business cable access and offers static IPs .
The cost is more than consumer level stuff , but not so expensive that it is n't affordable .
In fact , I 'm sure it probably compares in price to coloc fees , if not cheaper .
Some ISPs also does n't seem to bill on bandwidth used , so this might be a positive consideration.I do n't know your ( the OP ) situation , but it might be a better alternative .</tokentext>
<sentencetext>I second with checking with local ISPs and see if they have something that offers similar.
TWC where I live has business cable access and offers static IPs.
The cost is more than consumer level stuff, but not so expensive that it isn't affordable.
In fact, I'm sure it probably compares in price to coloc fees, if not cheaper.
Some ISPs also doesn't seem to bill on bandwidth used, so this might be a positive consideration.I don't know your (the OP) situation, but it might be a better alternative.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557080</id>
	<title>"Mandos"</title>
	<author>Anonymous</author>
	<datestamp>1261854720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><a href="http://wiki.fukt.bsnet.se/wiki/Mandos" title="bsnet.se" rel="nofollow">http://wiki.fukt.bsnet.se/wiki/Mandos</a> [bsnet.se]</p><p>Seems to do what you want, but requires another server somewhere on the internet in case of a reboot.</p></htmltext>
<tokenext>http : //wiki.fukt.bsnet.se/wiki/Mandos [ bsnet.se ] Seems to do what you want , but requires another server somewhere on the internet in case of a reboot .</tokentext>
<sentencetext>http://wiki.fukt.bsnet.se/wiki/Mandos [bsnet.se]Seems to do what you want, but requires another server somewhere on the internet in case of a reboot.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557514</id>
	<title>We will not do it again... no pr0n found</title>
	<author>Anonymous</author>
	<datestamp>1261858440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>We searched hard for pr0n in it in a moment of desperation, your server was taking too many hits... we only found OSS projects in it, what a waste of time!</p></htmltext>
<tokenext>We searched hard for pr0n in it in a moment of desperation , your server was taking too many hits... we only found OSS projects in it , what a waste of time !</tokentext>
<sentencetext>We searched hard for pr0n in it in a moment of desperation, your server was taking too many hits... we only found OSS projects in it, what a waste of time!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556876</id>
	<title>Re:If they do this..</title>
	<author>MightyMartian</author>
	<datestamp>1261852860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No fucking kidding.  I'd be looking for the door post haste if anyone in their tech team asked for my root password.</p></htmltext>
<tokenext>No fucking kidding .
I 'd be looking for the door post haste if anyone in their tech team asked for my root password .</tokentext>
<sentencetext>No fucking kidding.
I'd be looking for the door post haste if anyone in their tech team asked for my root password.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582</id>
	<title>Re:you might be our customer</title>
	<author>hacker</author>
	<datestamp>1261859100000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p> <em>"If you want full control over your hardware, you need to talk to the sales team and tell them that you want an unmanaged plan. The trade-off, of course, is that you have to deal with your own "WTF" problems from then on."</em></p></div> </blockquote><p>This <em>IS</em> an unmanaged plan. All the provide is ping and power, I do the rest. I manage the OS, the configuration and everything else. This is not VPS, I lease a physical server, and they don't touch it.</p></div>
	</htmltext>
<tokenext>" If you want full control over your hardware , you need to talk to the sales team and tell them that you want an unmanaged plan .
The trade-off , of course , is that you have to deal with your own " WTF " problems from then on .
" This IS an unmanaged plan .
All the provide is ping and power , I do the rest .
I manage the OS , the configuration and everything else .
This is not VPS , I lease a physical server , and they do n't touch it .</tokentext>
<sentencetext> "If you want full control over your hardware, you need to talk to the sales team and tell them that you want an unmanaged plan.
The trade-off, of course, is that you have to deal with your own "WTF" problems from then on.
" This IS an unmanaged plan.
All the provide is ping and power, I do the rest.
I manage the OS, the configuration and everything else.
This is not VPS, I lease a physical server, and they don't touch it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30568096</id>
	<title>Re:Name and Shame</title>
	<author>Anonymous</author>
	<datestamp>1261932180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>    *  Fire detection and prevention (with a gas like FM2000)<br>
&nbsp; &nbsp; &nbsp; &nbsp; * A big heavy door to avoid any access<br>
&nbsp; &nbsp; &nbsp; &nbsp; * Anti-static electrical installation<br>
&nbsp; &nbsp; &nbsp; &nbsp; * An employee that can access your server and replace parts (that you'd have in stock) when you go in holiday</p><p>If you didn't then that's not up to the level of ANY decent data center. Plus the cost of electricity AND a dedicated leased line with big bandwidth up and down makes it most of the time not worth the money compared to hosting in a data center, and often very dangerous (electric fire is the most important). Hosting ONE server at home is NEVER economical AND safe (you barely can have one of the 2, and most of the time none of them).</p></div><p>But he didn't ask or want any of those things.  He basically does not want any data center type of situation.</p><p>The one and only thing he states matters is to prevent a 3rd party with physical access from obtaining digital access.</p><p>The only possible way to do that is not let them have physical access.  So a data center in any form. be it real tier-1 colo, or 'billy joes basement isp', you can not do anything to prevent an attacker with physical access from getting digital access.</p><p>Running his production server at home with no power backup, frequent outages, home internet connectivity, and only himself for support is the only option until you get up to the point of spending multiple tens of millions on fortifying a small chunk of land against physical attack in order to move the server there.</p></div>
	</htmltext>
<tokenext>* Fire detection and prevention ( with a gas like FM2000 )         * A big heavy door to avoid any access         * Anti-static electrical installation         * An employee that can access your server and replace parts ( that you 'd have in stock ) when you go in holidayIf you did n't then that 's not up to the level of ANY decent data center .
Plus the cost of electricity AND a dedicated leased line with big bandwidth up and down makes it most of the time not worth the money compared to hosting in a data center , and often very dangerous ( electric fire is the most important ) .
Hosting ONE server at home is NEVER economical AND safe ( you barely can have one of the 2 , and most of the time none of them ) .But he did n't ask or want any of those things .
He basically does not want any data center type of situation.The one and only thing he states matters is to prevent a 3rd party with physical access from obtaining digital access.The only possible way to do that is not let them have physical access .
So a data center in any form .
be it real tier-1 colo , or 'billy joes basement isp ' , you can not do anything to prevent an attacker with physical access from getting digital access.Running his production server at home with no power backup , frequent outages , home internet connectivity , and only himself for support is the only option until you get up to the point of spending multiple tens of millions on fortifying a small chunk of land against physical attack in order to move the server there .</tokentext>
<sentencetext>    *  Fire detection and prevention (with a gas like FM2000)
        * A big heavy door to avoid any access
        * Anti-static electrical installation
        * An employee that can access your server and replace parts (that you'd have in stock) when you go in holidayIf you didn't then that's not up to the level of ANY decent data center.
Plus the cost of electricity AND a dedicated leased line with big bandwidth up and down makes it most of the time not worth the money compared to hosting in a data center, and often very dangerous (electric fire is the most important).
Hosting ONE server at home is NEVER economical AND safe (you barely can have one of the 2, and most of the time none of them).But he didn't ask or want any of those things.
He basically does not want any data center type of situation.The one and only thing he states matters is to prevent a 3rd party with physical access from obtaining digital access.The only possible way to do that is not let them have physical access.
So a data center in any form.
be it real tier-1 colo, or 'billy joes basement isp', you can not do anything to prevent an attacker with physical access from getting digital access.Running his production server at home with no power backup, frequent outages, home internet connectivity, and only himself for support is the only option until you get up to the point of spending multiple tens of millions on fortifying a small chunk of land against physical attack in order to move the server there.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560450</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557356</id>
	<title>If you are to change providers...</title>
	<author>lalena</author>
	<datestamp>1261857000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Don't ever go by web sites that rank the top 10 providers. Those are all paid placements.
<br>Sometimes good providers turn bad. Forums provide the most up to date info.
<br>I've found this site to provide useful info: <a href="http://www.webhostingtalk.com/" title="webhostingtalk.com">http://www.webhostingtalk.com/</a> [webhostingtalk.com]
<br>Just go with the opinions of those with lots of posts that don't appear to be promoting a single agenda.</htmltext>
<tokenext>Do n't ever go by web sites that rank the top 10 providers .
Those are all paid placements .
Sometimes good providers turn bad .
Forums provide the most up to date info .
I 've found this site to provide useful info : http : //www.webhostingtalk.com/ [ webhostingtalk.com ] Just go with the opinions of those with lots of posts that do n't appear to be promoting a single agenda .</tokentext>
<sentencetext>Don't ever go by web sites that rank the top 10 providers.
Those are all paid placements.
Sometimes good providers turn bad.
Forums provide the most up to date info.
I've found this site to provide useful info: http://www.webhostingtalk.com/ [webhostingtalk.com]
Just go with the opinions of those with lots of posts that don't appear to be promoting a single agenda.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559802</id>
	<title>Name the company or GTFO? :)</title>
	<author>BlahSnarto</author>
	<datestamp>1261835460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Chiming in late as usual<nobr> <wbr></nobr>:)</p><p>But from what i read the data center is in dallas?</p><p>I'm Curious who this is im thinking the Planet?</p></htmltext>
<tokenext>Chiming in late as usual : ) But from what i read the data center is in dallas ? I 'm Curious who this is im thinking the Planet ?</tokentext>
<sentencetext>Chiming in late as usual :)But from what i read the data center is in dallas?I'm Curious who this is im thinking the Planet?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556962</id>
	<title>More details please?</title>
	<author>bsDaemon</author>
	<datestamp>1261853580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Are you co-locating a machine you own outright, or do you have a "dedicated hosting" package with the company?  I was a system admin at a web hosting company for a long while, and on our dedicated packages if a customer took root access they had to inform us if they changed the root password.  We also kept root ssh keys to all of the servers just in case someone wanted to try and be a dick about it.  The logic is the machine is actually our property and the customer is renting its use, just as most apartment complexes will keep master keys to the units.<br><br>However, if you own the machine and just have it stuck some place, essentially just paying to rack it and plug into the network, then you may just want to create a limited account that has read permissions on syslog stuff and let them have that for investigative purposes when you need to request access.  But, if it's not their machine then they don't need to be shutting you off, booting single-users and rummaging through your stuff.</htmltext>
<tokenext>Are you co-locating a machine you own outright , or do you have a " dedicated hosting " package with the company ?
I was a system admin at a web hosting company for a long while , and on our dedicated packages if a customer took root access they had to inform us if they changed the root password .
We also kept root ssh keys to all of the servers just in case someone wanted to try and be a dick about it .
The logic is the machine is actually our property and the customer is renting its use , just as most apartment complexes will keep master keys to the units.However , if you own the machine and just have it stuck some place , essentially just paying to rack it and plug into the network , then you may just want to create a limited account that has read permissions on syslog stuff and let them have that for investigative purposes when you need to request access .
But , if it 's not their machine then they do n't need to be shutting you off , booting single-users and rummaging through your stuff .</tokentext>
<sentencetext>Are you co-locating a machine you own outright, or do you have a "dedicated hosting" package with the company?
I was a system admin at a web hosting company for a long while, and on our dedicated packages if a customer took root access they had to inform us if they changed the root password.
We also kept root ssh keys to all of the servers just in case someone wanted to try and be a dick about it.
The logic is the machine is actually our property and the customer is renting its use, just as most apartment complexes will keep master keys to the units.However, if you own the machine and just have it stuck some place, essentially just paying to rack it and plug into the network, then you may just want to create a limited account that has read permissions on syslog stuff and let them have that for investigative purposes when you need to request access.
But, if it's not their machine then they don't need to be shutting you off, booting single-users and rummaging through your stuff.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558424</id>
	<title>Re:If they do this..</title>
	<author>Anonymous</author>
	<datestamp>1261822620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><i>It may be a little harsh, but your Attorney General cannot refuse to prosecute this, as it would set a precedent. Any refusal to prosecute, would allow for a lawsuit of selective enforcement of the law</i> <p>
You know nothing about the law, and would be best served by shutting the fuck up about things you don't understand.</p></htmltext>
<tokenext>It may be a little harsh , but your Attorney General can not refuse to prosecute this , as it would set a precedent .
Any refusal to prosecute , would allow for a lawsuit of selective enforcement of the law You know nothing about the law , and would be best served by shutting the fuck up about things you do n't understand .</tokentext>
<sentencetext>It may be a little harsh, but your Attorney General cannot refuse to prosecute this, as it would set a precedent.
Any refusal to prosecute, would allow for a lawsuit of selective enforcement of the law 
You know nothing about the law, and would be best served by shutting the fuck up about things you don't understand.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560996</id>
	<title>Physical Access is Root Access.</title>
	<author>Anonymous</author>
	<datestamp>1261853400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>From what I gather you are renting a machine at their Data Center/Co-Location (or whatever buzz-word you're used to using for a space designed to house servers).  Honestly I don't see an issue with them rooting their own machine to debug a problem you keep complaining about.</p><p>If you rented rack space at a Data Center and put in your own machines; then you might have something to complain about.  In which case full disk encryption with a hardened kernel will keep all but the most determined people away from your data.</p></htmltext>
<tokenext>From what I gather you are renting a machine at their Data Center/Co-Location ( or whatever buzz-word you 're used to using for a space designed to house servers ) .
Honestly I do n't see an issue with them rooting their own machine to debug a problem you keep complaining about.If you rented rack space at a Data Center and put in your own machines ; then you might have something to complain about .
In which case full disk encryption with a hardened kernel will keep all but the most determined people away from your data .</tokentext>
<sentencetext>From what I gather you are renting a machine at their Data Center/Co-Location (or whatever buzz-word you're used to using for a space designed to house servers).
Honestly I don't see an issue with them rooting their own machine to debug a problem you keep complaining about.If you rented rack space at a Data Center and put in your own machines; then you might have something to complain about.
In which case full disk encryption with a hardened kernel will keep all but the most determined people away from your data.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559642</id>
	<title>be your own hosting provider...</title>
	<author>NynexNinja</author>
	<datestamp>1261833480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've been running my own servers for over 20 years and have never looked back.  How can you really trust that your machines are not being compromised by multiple third parties?</htmltext>
<tokenext>I 've been running my own servers for over 20 years and have never looked back .
How can you really trust that your machines are not being compromised by multiple third parties ?</tokentext>
<sentencetext>I've been running my own servers for over 20 years and have never looked back.
How can you really trust that your machines are not being compromised by multiple third parties?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30588030</id>
	<title>Re:If they do this..</title>
	<author>Anonymous</author>
	<datestamp>1262087340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why not just disable the process that allows them to log in as root?  It's not like they're cracking your box.</p></htmltext>
<tokenext>Why not just disable the process that allows them to log in as root ?
It 's not like they 're cracking your box .</tokentext>
<sentencetext>Why not just disable the process that allows them to log in as root?
It's not like they're cracking your box.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557636</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557306</id>
	<title>Re:If they do this..</title>
	<author>DarthBart</author>
	<datestamp>1261856640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs. You diagnose the cause of the problem and take the car to the mechanic. You ask the mechanic to fix your car under warranty and he asks you for your keys. You refuse to give him the keys.</i></p><p>In this case, its like calling the "traffic hotline" to ask about a possible traffic jam and then having someone come over and hotwire your car and drive it around the interstate looking for the traffic jam.</p></htmltext>
<tokenext>( Car Analogy ) - It 's like leasing a car with a repair warranty and wanting to do your own repairs .
You diagnose the cause of the problem and take the car to the mechanic .
You ask the mechanic to fix your car under warranty and he asks you for your keys .
You refuse to give him the keys.In this case , its like calling the " traffic hotline " to ask about a possible traffic jam and then having someone come over and hotwire your car and drive it around the interstate looking for the traffic jam .</tokentext>
<sentencetext>(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs.
You diagnose the cause of the problem and take the car to the mechanic.
You ask the mechanic to fix your car under warranty and he asks you for your keys.
You refuse to give him the keys.In this case, its like calling the "traffic hotline" to ask about a possible traffic jam and then having someone come over and hotwire your car and drive it around the interstate looking for the traffic jam.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560358</id>
	<title>Why don't you trust your host???</title>
	<author>GPLHost-Thomas</author>
	<datestamp>1261843980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There's something that I don't understand here. If you don't trust the hosting company you are working with, why don't you host with them in the first place? If you believe that when they access your server, there is a risk that they will do something else than trying to solve the issue, then don't host with them. You should be able to trust your web hosting company to the point that you can give them the root on your server. Otherwise, you have made a bad choice, end of the story.<br>
<br>
Ultimately, if you really want to keep everything private to the last point, then there's only one way. Get a server from a company that offers an integrated KVM over IP on the dedicated server, and encrypt your partitions. That way, even if they access physically the server, they wont have the passphrase needed to boot it. Of course, the drawback is that if the server reboots for whatever reason (power outage, etc.) then you will have to login in the KVM to type the passphrase, which can be annoying. Hummm... maybe you'll tell me they can try that USB boot so they can read the memory and hack access to the passphrase in the RAM after a quick reboot... But well, I suppose most host would give-up seeing that your partitions are encrypted.<br>
<br>
But again, the best solution here is still to be with a trust worthy host were you do not fear to give the root, IMHO.<br>
<br>
Now, you just wrote about your host trying to hide the fact that they tried to force themselves in your server. This is clearly being dishonest, and there is a big issue here. That means you CANNOT trust them to tell the truth, and proves that you have to move away. There's no way you should stay with liars.<br>
<br>
Just my 2 cents...</htmltext>
<tokenext>There 's something that I do n't understand here .
If you do n't trust the hosting company you are working with , why do n't you host with them in the first place ?
If you believe that when they access your server , there is a risk that they will do something else than trying to solve the issue , then do n't host with them .
You should be able to trust your web hosting company to the point that you can give them the root on your server .
Otherwise , you have made a bad choice , end of the story .
Ultimately , if you really want to keep everything private to the last point , then there 's only one way .
Get a server from a company that offers an integrated KVM over IP on the dedicated server , and encrypt your partitions .
That way , even if they access physically the server , they wont have the passphrase needed to boot it .
Of course , the drawback is that if the server reboots for whatever reason ( power outage , etc .
) then you will have to login in the KVM to type the passphrase , which can be annoying .
Hummm... maybe you 'll tell me they can try that USB boot so they can read the memory and hack access to the passphrase in the RAM after a quick reboot... But well , I suppose most host would give-up seeing that your partitions are encrypted .
But again , the best solution here is still to be with a trust worthy host were you do not fear to give the root , IMHO .
Now , you just wrote about your host trying to hide the fact that they tried to force themselves in your server .
This is clearly being dishonest , and there is a big issue here .
That means you CAN NOT trust them to tell the truth , and proves that you have to move away .
There 's no way you should stay with liars .
Just my 2 cents.. .</tokentext>
<sentencetext>There's something that I don't understand here.
If you don't trust the hosting company you are working with, why don't you host with them in the first place?
If you believe that when they access your server, there is a risk that they will do something else than trying to solve the issue, then don't host with them.
You should be able to trust your web hosting company to the point that you can give them the root on your server.
Otherwise, you have made a bad choice, end of the story.
Ultimately, if you really want to keep everything private to the last point, then there's only one way.
Get a server from a company that offers an integrated KVM over IP on the dedicated server, and encrypt your partitions.
That way, even if they access physically the server, they wont have the passphrase needed to boot it.
Of course, the drawback is that if the server reboots for whatever reason (power outage, etc.
) then you will have to login in the KVM to type the passphrase, which can be annoying.
Hummm... maybe you'll tell me they can try that USB boot so they can read the memory and hack access to the passphrase in the RAM after a quick reboot... But well, I suppose most host would give-up seeing that your partitions are encrypted.
But again, the best solution here is still to be with a trust worthy host were you do not fear to give the root, IMHO.
Now, you just wrote about your host trying to hide the fact that they tried to force themselves in your server.
This is clearly being dishonest, and there is a big issue here.
That means you CANNOT trust them to tell the truth, and proves that you have to move away.
There's no way you should stay with liars.
Just my 2 cents...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557960</id>
	<title>Re:You're complicating things.</title>
	<author>socsoc</author>
	<datestamp>1261818720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If this is so crucial to your business (which is conflicting between your posts and TFS, so I can't figure out if it's hobby/personal or business) but, host your own equipment at a reputable colo...</htmltext>
<tokenext>If this is so crucial to your business ( which is conflicting between your posts and TFS , so I ca n't figure out if it 's hobby/personal or business ) but , host your own equipment at a reputable colo.. .</tokentext>
<sentencetext>If this is so crucial to your business (which is conflicting between your posts and TFS, so I can't figure out if it's hobby/personal or business) but, host your own equipment at a reputable colo...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556928</id>
	<title>Change providers and harden your server...</title>
	<author>Anonymous</author>
	<datestamp>1261853280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>and stick a BSD firewall in front of it.   Good grief.  The main reason servers get compromised  is because the server has been left vulnerable.  If you can run a server then you can harden it.  Do a search on "server hardening rules linux|redhat|win|mac|etc" and you should find some good stuff.</p><p>http://www.freebsd.org/doc/en/books/handbook/firewalls.html</p><p>If you don't feel comfortable with this then talk to a techie friend or hire a computer science/engineering student to do it for you.<nobr> <wbr></nobr>....and change providers.</p><p>gott im himmel</p></htmltext>
<tokenext>and stick a BSD firewall in front of it .
Good grief .
The main reason servers get compromised is because the server has been left vulnerable .
If you can run a server then you can harden it .
Do a search on " server hardening rules linux | redhat | win | mac | etc " and you should find some good stuff.http : //www.freebsd.org/doc/en/books/handbook/firewalls.htmlIf you do n't feel comfortable with this then talk to a techie friend or hire a computer science/engineering student to do it for you .
....and change providers.gott im himmel</tokentext>
<sentencetext>and stick a BSD firewall in front of it.
Good grief.
The main reason servers get compromised  is because the server has been left vulnerable.
If you can run a server then you can harden it.
Do a search on "server hardening rules linux|redhat|win|mac|etc" and you should find some good stuff.http://www.freebsd.org/doc/en/books/handbook/firewalls.htmlIf you don't feel comfortable with this then talk to a techie friend or hire a computer science/engineering student to do it for you.
....and change providers.gott im himmel</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30586712</id>
	<title>Re:Stop being a douche</title>
	<author>captain\_cthulhu</author>
	<datestamp>1262082060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I (and my colleagues at work) remotely manage a lot of servers in many data centers worldwide. We use  a serial terminal server (cyclades) which allows for SSH connectivity (then over serial) to any machine configured and plugged into the serial port. this allows us to reboot the machine and remain connected to it for bios changes, OS rebuilds, single user mode, etc... we also use power columns that have remote control options like powering off a specific outlet so we can do cold boots. finally, we have a Perle serial device on a separate IP block in case we lose the data center's router or other non-all-encompassing problem upstream from us.

seems like the serial terminal server would do what you want. it is a separate device that needs it's own IP but otherwise will allow you to control the machine from power-on to boot-up so you could configure linux anyway you like. it's not end-to-end encryption although SSH is encrypted and you can configure the cyclades device to use it exclusively.

but now it seems you don't really own any of the hardware and therefore you are not truly colo and therefore can't walk into the datacenter with new equipment and set it up yourself. the problem here is that you don't own the hardware, so you don't have much leverage in the situation. you need to physically own the hardware in your future hosting plans. good luck dude.</htmltext>
<tokenext>I ( and my colleagues at work ) remotely manage a lot of servers in many data centers worldwide .
We use a serial terminal server ( cyclades ) which allows for SSH connectivity ( then over serial ) to any machine configured and plugged into the serial port .
this allows us to reboot the machine and remain connected to it for bios changes , OS rebuilds , single user mode , etc... we also use power columns that have remote control options like powering off a specific outlet so we can do cold boots .
finally , we have a Perle serial device on a separate IP block in case we lose the data center 's router or other non-all-encompassing problem upstream from us .
seems like the serial terminal server would do what you want .
it is a separate device that needs it 's own IP but otherwise will allow you to control the machine from power-on to boot-up so you could configure linux anyway you like .
it 's not end-to-end encryption although SSH is encrypted and you can configure the cyclades device to use it exclusively .
but now it seems you do n't really own any of the hardware and therefore you are not truly colo and therefore ca n't walk into the datacenter with new equipment and set it up yourself .
the problem here is that you do n't own the hardware , so you do n't have much leverage in the situation .
you need to physically own the hardware in your future hosting plans .
good luck dude .</tokentext>
<sentencetext>I (and my colleagues at work) remotely manage a lot of servers in many data centers worldwide.
We use  a serial terminal server (cyclades) which allows for SSH connectivity (then over serial) to any machine configured and plugged into the serial port.
this allows us to reboot the machine and remain connected to it for bios changes, OS rebuilds, single user mode, etc... we also use power columns that have remote control options like powering off a specific outlet so we can do cold boots.
finally, we have a Perle serial device on a separate IP block in case we lose the data center's router or other non-all-encompassing problem upstream from us.
seems like the serial terminal server would do what you want.
it is a separate device that needs it's own IP but otherwise will allow you to control the machine from power-on to boot-up so you could configure linux anyway you like.
it's not end-to-end encryption although SSH is encrypted and you can configure the cyclades device to use it exclusively.
but now it seems you don't really own any of the hardware and therefore you are not truly colo and therefore can't walk into the datacenter with new equipment and set it up yourself.
the problem here is that you don't own the hardware, so you don't have much leverage in the situation.
you need to physically own the hardware in your future hosting plans.
good luck dude.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557532</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560070</id>
	<title>Re:If they do this..</title>
	<author>Chysn</author>
	<datestamp>1261839420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>I might ask for more evidence that the provider actually rooted the server before pronouncing judgment.</p></div></blockquote><p>This is Slashdot.  You're entitled to pronounce whatever judgment you want with whatever you deem as "evidence."</p></div>
	</htmltext>
<tokenext>I might ask for more evidence that the provider actually rooted the server before pronouncing judgment.This is Slashdot .
You 're entitled to pronounce whatever judgment you want with whatever you deem as " evidence .
"</tokentext>
<sentencetext>I might ask for more evidence that the provider actually rooted the server before pronouncing judgment.This is Slashdot.
You're entitled to pronounce whatever judgment you want with whatever you deem as "evidence.
"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556890</id>
	<title>Encrypted LVM</title>
	<author>Ender305</author>
	<datestamp>1261852980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You could create a number of LVM partitions and encrypt them, then mount them once the machine boots, but I'm not sure if that will fully prevent them from rooting your machine.</htmltext>
<tokenext>You could create a number of LVM partitions and encrypt them , then mount them once the machine boots , but I 'm not sure if that will fully prevent them from rooting your machine .</tokentext>
<sentencetext>You could create a number of LVM partitions and encrypt them, then mount them once the machine boots, but I'm not sure if that will fully prevent them from rooting your machine.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560454</id>
	<title>I don't *want* root.</title>
	<author>pushf popf</author>
	<datestamp>1261845300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I worked for a large ISP that did both managed and colo hosting. The big secret is that I already have root on the boxes we manage, and I <strong>don't want root</strong> on yours. If you want to send in part of a log file, I'm happy to take a look, but I wouldn't login to your box on a bet.<br> <br>

When your box craps out and you loose [insert valuable service/data here], you send in the lawyers and my boss comes by to ask what happened, one of the biggest thrills of my life is being able to say "Beats me, we don't have a login for that box."<br> <br>

And if we're managing it, <strong>you</strong> don't have root, and your box won't crap out because we've got 500 others just like it that are working just fine and yours is nothing special.</htmltext>
<tokenext>I worked for a large ISP that did both managed and colo hosting .
The big secret is that I already have root on the boxes we manage , and I do n't want root on yours .
If you want to send in part of a log file , I 'm happy to take a look , but I would n't login to your box on a bet .
When your box craps out and you loose [ insert valuable service/data here ] , you send in the lawyers and my boss comes by to ask what happened , one of the biggest thrills of my life is being able to say " Beats me , we do n't have a login for that box .
" And if we 're managing it , you do n't have root , and your box wo n't crap out because we 've got 500 others just like it that are working just fine and yours is nothing special .</tokentext>
<sentencetext>I worked for a large ISP that did both managed and colo hosting.
The big secret is that I already have root on the boxes we manage, and I don't want root on yours.
If you want to send in part of a log file, I'm happy to take a look, but I wouldn't login to your box on a bet.
When your box craps out and you loose [insert valuable service/data here], you send in the lawyers and my boss comes by to ask what happened, one of the biggest thrills of my life is being able to say "Beats me, we don't have a login for that box.
" 

And if we're managing it, you don't have root, and your box won't crap out because we've got 500 others just like it that are working just fine and yours is nothing special.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562324</id>
	<title>Check your contract.</title>
	<author>Anonymous</author>
	<datestamp>1261916460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you are renting a dedicated server, the server is not actually owned by you.  The provider technically has the right to do anything.  Although he is tied to your SLA, meaning any downtime longer than X will automatically result in a Y credit if you ask for it.  They have charts.</p><p>although you can sometime ask them to put a flag on you account saying "don't touch the server unless absolutely necessary", not all provider or agent will follow it.  They will still mostly investigate if you open a few tickets complaining about non-reproducible issues.  They will look into their logs, because customer's satisfaction is important, then seeing nothing, they investigate the server for any signs of hardware failure.  Your failure to provide a root password led to their forced investigation.  It is most likely in your contract.  They do it to protect themselves ( The SLA again ).</p><p>If you have a collocation server however, different story altogether: By all means sue their ***.  If it is in your contract, switch provider.  No questions.</p></htmltext>
<tokenext>If you are renting a dedicated server , the server is not actually owned by you .
The provider technically has the right to do anything .
Although he is tied to your SLA , meaning any downtime longer than X will automatically result in a Y credit if you ask for it .
They have charts.although you can sometime ask them to put a flag on you account saying " do n't touch the server unless absolutely necessary " , not all provider or agent will follow it .
They will still mostly investigate if you open a few tickets complaining about non-reproducible issues .
They will look into their logs , because customer 's satisfaction is important , then seeing nothing , they investigate the server for any signs of hardware failure .
Your failure to provide a root password led to their forced investigation .
It is most likely in your contract .
They do it to protect themselves ( The SLA again ) .If you have a collocation server however , different story altogether : By all means sue their * * * .
If it is in your contract , switch provider .
No questions .</tokentext>
<sentencetext>If you are renting a dedicated server, the server is not actually owned by you.
The provider technically has the right to do anything.
Although he is tied to your SLA, meaning any downtime longer than X will automatically result in a Y credit if you ask for it.
They have charts.although you can sometime ask them to put a flag on you account saying "don't touch the server unless absolutely necessary", not all provider or agent will follow it.
They will still mostly investigate if you open a few tickets complaining about non-reproducible issues.
They will look into their logs, because customer's satisfaction is important, then seeing nothing, they investigate the server for any signs of hardware failure.
Your failure to provide a root password led to their forced investigation.
It is most likely in your contract.
They do it to protect themselves ( The SLA again ).If you have a collocation server however, different story altogether: By all means sue their ***.
If it is in your contract, switch provider.
No questions.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560876</id>
	<title>Been Coloing for awhile</title>
	<author>physburn</author>
	<datestamp>1261851180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>and not once have the hosting company asked for a password
or tried to access the machine. You might want to change providers.
While its easy to set up remote access to a machine. Blocking off
access from the main keyboard and screen, might not be a good
idea, and you're regret it if there's a problem with the networking
system.
<p>
---
</p><p>
<a href="http://www.feeddistiller.com/blogs/Cloud\%20Computing/feed.html" title="feeddistiller.com">Cloud Computing</a> [feeddistiller.com] Feed @ <a href="http://www.feeddistiller.com/" title="feeddistiller.com">Feed Distiller</a> [feeddistiller.com]</p></htmltext>
<tokenext>and not once have the hosting company asked for a password or tried to access the machine .
You might want to change providers .
While its easy to set up remote access to a machine .
Blocking off access from the main keyboard and screen , might not be a good idea , and you 're regret it if there 's a problem with the networking system .
--- Cloud Computing [ feeddistiller.com ] Feed @ Feed Distiller [ feeddistiller.com ]</tokentext>
<sentencetext>and not once have the hosting company asked for a password
or tried to access the machine.
You might want to change providers.
While its easy to set up remote access to a machine.
Blocking off
access from the main keyboard and screen, might not be a good
idea, and you're regret it if there's a problem with the networking
system.
---

Cloud Computing [feeddistiller.com] Feed @ Feed Distiller [feeddistiller.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</id>
	<title>Re:You're complicating things.</title>
	<author>hacker</author>
	<datestamp>1261858320000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p> <em>"Switch providers. Plenty offer remote reboot and serial console or KVM for both VMs or physical servers, which would allow you to go crazy with custom encrypted partitions etc."</em></p></div> </blockquote><p>They offer KVM access, at $35.00/day, which in this case I refuse to pay to fix what they broke, outside of the context of the server. They migrated me from one chassis to another with completely different hardware, causing my machine to go offline. They want me to pay $35.00 for 24-hours of KVM access to reconfigure the network to support the hardware they moved things to.

</p><p>Alternately, they want me to hand over the root password (not a privileged account, but THE root password), so they can do it themselves. Since I installed, configured and manage the OS entirely on this machine, and they've demonstrated their ineptitude before, I'm not giving them root. Ever.</p><blockquote><div><p> <em>"I'd also like to know how you *know* it's a hardware or network issue outside of your server. How do you know it's not your NIC driver hanging up? Older e1000 drivers (super common card in the hosting industry) are quite flaky. What research have you done outside of your internal monitoring?"</em></p></div> </blockquote><p>Because this server has been running 24x7 for about 3 years without a single outstanding issue. When they migrated it from Savvis to some datacenter in Dallas 2 months ago, I've had <strong> <em>no less than 20 separate outages</em> </strong>, while the underlying OS and application stack itself has not changed in any way to facilitate those outages.

</p><p>In every single case, they demand that I give them the root password, so they can diagnose the issues on the machine. In every single case, I've shown them nagios, ntop, hotsanic, sar, etc. logs demonstrating that the OS itself is not the cause of the outages.

</p><p>For example, since this migration to Dallas, every other Sunday between 7:00am and 8:00am EST, my server's load goes over 100 as incoming connections spike over 700/sec., sendmail refuses connections due to the load, and the box seizes up. The logs show that the connections are established and then hang. <em>NOTHING</em> on the machine triggers every other Sunday between these hours that would cause that.

</p><p>Only a few days ago, they indicated that the NIC on the server may be causing the issues. I'm down 2-3 hours every other Sunday because of this.

</p><p>They're not asking for the logs, they're asking for root. That's a completely separate (and unacceptable) solution to their own problems outside of the box itself.</p></div>
	</htmltext>
<tokenext>" Switch providers .
Plenty offer remote reboot and serial console or KVM for both VMs or physical servers , which would allow you to go crazy with custom encrypted partitions etc .
" They offer KVM access , at $ 35.00/day , which in this case I refuse to pay to fix what they broke , outside of the context of the server .
They migrated me from one chassis to another with completely different hardware , causing my machine to go offline .
They want me to pay $ 35.00 for 24-hours of KVM access to reconfigure the network to support the hardware they moved things to .
Alternately , they want me to hand over the root password ( not a privileged account , but THE root password ) , so they can do it themselves .
Since I installed , configured and manage the OS entirely on this machine , and they 've demonstrated their ineptitude before , I 'm not giving them root .
Ever. " I 'd also like to know how you * know * it 's a hardware or network issue outside of your server .
How do you know it 's not your NIC driver hanging up ?
Older e1000 drivers ( super common card in the hosting industry ) are quite flaky .
What research have you done outside of your internal monitoring ?
" Because this server has been running 24x7 for about 3 years without a single outstanding issue .
When they migrated it from Savvis to some datacenter in Dallas 2 months ago , I 've had no less than 20 separate outages , while the underlying OS and application stack itself has not changed in any way to facilitate those outages .
In every single case , they demand that I give them the root password , so they can diagnose the issues on the machine .
In every single case , I 've shown them nagios , ntop , hotsanic , sar , etc .
logs demonstrating that the OS itself is not the cause of the outages .
For example , since this migration to Dallas , every other Sunday between 7 : 00am and 8 : 00am EST , my server 's load goes over 100 as incoming connections spike over 700/sec. , sendmail refuses connections due to the load , and the box seizes up .
The logs show that the connections are established and then hang .
NOTHING on the machine triggers every other Sunday between these hours that would cause that .
Only a few days ago , they indicated that the NIC on the server may be causing the issues .
I 'm down 2-3 hours every other Sunday because of this .
They 're not asking for the logs , they 're asking for root .
That 's a completely separate ( and unacceptable ) solution to their own problems outside of the box itself .</tokentext>
<sentencetext> "Switch providers.
Plenty offer remote reboot and serial console or KVM for both VMs or physical servers, which would allow you to go crazy with custom encrypted partitions etc.
" They offer KVM access, at $35.00/day, which in this case I refuse to pay to fix what they broke, outside of the context of the server.
They migrated me from one chassis to another with completely different hardware, causing my machine to go offline.
They want me to pay $35.00 for 24-hours of KVM access to reconfigure the network to support the hardware they moved things to.
Alternately, they want me to hand over the root password (not a privileged account, but THE root password), so they can do it themselves.
Since I installed, configured and manage the OS entirely on this machine, and they've demonstrated their ineptitude before, I'm not giving them root.
Ever. "I'd also like to know how you *know* it's a hardware or network issue outside of your server.
How do you know it's not your NIC driver hanging up?
Older e1000 drivers (super common card in the hosting industry) are quite flaky.
What research have you done outside of your internal monitoring?
" Because this server has been running 24x7 for about 3 years without a single outstanding issue.
When they migrated it from Savvis to some datacenter in Dallas 2 months ago, I've had  no less than 20 separate outages , while the underlying OS and application stack itself has not changed in any way to facilitate those outages.
In every single case, they demand that I give them the root password, so they can diagnose the issues on the machine.
In every single case, I've shown them nagios, ntop, hotsanic, sar, etc.
logs demonstrating that the OS itself is not the cause of the outages.
For example, since this migration to Dallas, every other Sunday between 7:00am and 8:00am EST, my server's load goes over 100 as incoming connections spike over 700/sec., sendmail refuses connections due to the load, and the box seizes up.
The logs show that the connections are established and then hang.
NOTHING on the machine triggers every other Sunday between these hours that would cause that.
Only a few days ago, they indicated that the NIC on the server may be causing the issues.
I'm down 2-3 hours every other Sunday because of this.
They're not asking for the logs, they're asking for root.
That's a completely separate (and unacceptable) solution to their own problems outside of the box itself.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30588718</id>
	<title>Server Access</title>
	<author>apersonofinterest</author>
	<datestamp>1262090880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Oh yeah, I forgot....<br>
<br>
Tell everyone how it worked once you possibly agreed to pay for that KVM that you wanted for free.<br>
<br>
I believe that it is possible that your server is online and has possibly been online for a couple of days now....<br>
<br>
And you are still bitching about it like you don't have access.  I hope I never find out that you have a server hosted at the company I work for because I will make sure that management see's this post and the defamation of character to said company and point out that we don't need anyone here that acts like a little girl who was told she can't play on the swing.</htmltext>
<tokenext>Oh yeah , I forgot... . Tell everyone how it worked once you possibly agreed to pay for that KVM that you wanted for free .
I believe that it is possible that your server is online and has possibly been online for a couple of days now... . And you are still bitching about it like you do n't have access .
I hope I never find out that you have a server hosted at the company I work for because I will make sure that management see 's this post and the defamation of character to said company and point out that we do n't need anyone here that acts like a little girl who was told she ca n't play on the swing .</tokentext>
<sentencetext>Oh yeah, I forgot....

Tell everyone how it worked once you possibly agreed to pay for that KVM that you wanted for free.
I believe that it is possible that your server is online and has possibly been online for a couple of days now....

And you are still bitching about it like you don't have access.
I hope I never find out that you have a server hosted at the company I work for because I will make sure that management see's this post and the defamation of character to said company and point out that we don't need anyone here that acts like a little girl who was told she can't play on the swing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557060</id>
	<title>Some solutions...</title>
	<author>Anonymous</author>
	<datestamp>1261854480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How about:</p><p>a) when they ask for root, change it to something innocuous, let them log in and do their stuff, then change it back.</p><p>b) change hosting providers.</p><p>c) host it yourself.  Get a business class internet connection to your office/home/etc, rig up a closet with power and A/C. And if you need "five nines", get a second power provider and a UPS, and a second internet connection.</p><p>Ultimately, physical access is everything.</p><p>And yeah, why are you asking for help if you're not going to let them help you?  Are you just seeking to prove that they're to blame?  That seems like a waste of time given option b).  Do you need to have the system locked down so that absolutely no one else can gain root access?  That leaves you with option c).</p></htmltext>
<tokenext>How about : a ) when they ask for root , change it to something innocuous , let them log in and do their stuff , then change it back.b ) change hosting providers.c ) host it yourself .
Get a business class internet connection to your office/home/etc , rig up a closet with power and A/C .
And if you need " five nines " , get a second power provider and a UPS , and a second internet connection.Ultimately , physical access is everything.And yeah , why are you asking for help if you 're not going to let them help you ?
Are you just seeking to prove that they 're to blame ?
That seems like a waste of time given option b ) .
Do you need to have the system locked down so that absolutely no one else can gain root access ?
That leaves you with option c ) .</tokentext>
<sentencetext>How about:a) when they ask for root, change it to something innocuous, let them log in and do their stuff, then change it back.b) change hosting providers.c) host it yourself.
Get a business class internet connection to your office/home/etc, rig up a closet with power and A/C.
And if you need "five nines", get a second power provider and a UPS, and a second internet connection.Ultimately, physical access is everything.And yeah, why are you asking for help if you're not going to let them help you?
Are you just seeking to prove that they're to blame?
That seems like a waste of time given option b).
Do you need to have the system locked down so that absolutely no one else can gain root access?
That leaves you with option c).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558850</id>
	<title>Re:You're complicating things.</title>
	<author>Anonymous</author>
	<datestamp>1261825860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>$35 a DAY??</p><p>Here you get <a href="http://www.1und1.info/xml/order/ServerPremiumSingleCoreS;jsessionid=D69CEEEE26EE6277ED13BEBE7C297E89.TCpfix153a?\_\_frame=\_top&amp;\_\_lf=Static&amp;ordernow=true&amp;linkType=&amp;linkOrigin=ServerPremium" title="1und1.info">a server with a serial console for 40&euro; a MONTH!</a> [1und1.info]</p></htmltext>
<tokenext>$ 35 a DAY ?
? Here you get a server with a serial console for 40    a MONTH !
[ 1und1.info ]</tokentext>
<sentencetext>$35 a DAY?
?Here you get a server with a serial console for 40€ a MONTH!
[1und1.info]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559808</id>
	<title>Couple observations...</title>
	<author>wneto</author>
	<datestamp>1261835580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>First of all, IANASA but i play one on tv (not really).<br>It seems to me both sides are doing it wrong. I understand you can only put so much information on Ask Slashdot before getting ignored by the tl;dr crowd so I might be wrong as well. Anyways, here it goes:
<br> <br>
1) You said "I have a heavily-hit public server (web, mail, cvs/svn/git, dns, etc.) that runs a few dozen OSS project websites...".
<br>
Too many eggs in one basket in my opinion. No wonder you are pissed about outages. It sounds like you have one beefy server capable of running multiple virtualized OS instances (encrypted nonetheless).
So why not just cancel your dedicated service and get VPS from multiple providers? That way you would have enough redundancy (e-mail, dns, rsync, HA/Varnish, whatever), none of the headaches of hardware/virtualization and save money while at it. Managing wouldn't be harder considering your proposition of vmware/uml. Also easier to move from your server bit by bit. Start with DNS, then e-mail, then web, then... You can take your time as it won't cost you much upfront (zero?) or monthly (sub $50) and gives you the ability to scale up or down the resources to acomodate the workload and cost.
<br> <br>
2) You said "When I file 'WTF?'-style support tickets to the provider through their web-based ticketing system"
<br>
Do you have the option to call the provider? If not, you are doing it wrong. From my experience, over 80\% of all ticket answers are canned responses. If possible, try calling (if you didn't yet) and get someone that has the power to fix the issue to talk to you. When you reach a dead end, ask to be transfered to the legal dept to discuss your contract/sla/whatever. If they don't have one, ask where you should send the legal papers. If everything fails, try the BBB.
<br> <br>
Just my humble opinion. Excuse my poor english as it's not my first language.</htmltext>
<tokenext>First of all , IANASA but i play one on tv ( not really ) .It seems to me both sides are doing it wrong .
I understand you can only put so much information on Ask Slashdot before getting ignored by the tl ; dr crowd so I might be wrong as well .
Anyways , here it goes : 1 ) You said " I have a heavily-hit public server ( web , mail , cvs/svn/git , dns , etc .
) that runs a few dozen OSS project websites... " .
Too many eggs in one basket in my opinion .
No wonder you are pissed about outages .
It sounds like you have one beefy server capable of running multiple virtualized OS instances ( encrypted nonetheless ) .
So why not just cancel your dedicated service and get VPS from multiple providers ?
That way you would have enough redundancy ( e-mail , dns , rsync , HA/Varnish , whatever ) , none of the headaches of hardware/virtualization and save money while at it .
Managing would n't be harder considering your proposition of vmware/uml .
Also easier to move from your server bit by bit .
Start with DNS , then e-mail , then web , then... You can take your time as it wo n't cost you much upfront ( zero ?
) or monthly ( sub $ 50 ) and gives you the ability to scale up or down the resources to acomodate the workload and cost .
2 ) You said " When I file 'WTF ?
'-style support tickets to the provider through their web-based ticketing system " Do you have the option to call the provider ?
If not , you are doing it wrong .
From my experience , over 80 \ % of all ticket answers are canned responses .
If possible , try calling ( if you did n't yet ) and get someone that has the power to fix the issue to talk to you .
When you reach a dead end , ask to be transfered to the legal dept to discuss your contract/sla/whatever .
If they do n't have one , ask where you should send the legal papers .
If everything fails , try the BBB .
Just my humble opinion .
Excuse my poor english as it 's not my first language .</tokentext>
<sentencetext>First of all, IANASA but i play one on tv (not really).It seems to me both sides are doing it wrong.
I understand you can only put so much information on Ask Slashdot before getting ignored by the tl;dr crowd so I might be wrong as well.
Anyways, here it goes:
 
1) You said "I have a heavily-hit public server (web, mail, cvs/svn/git, dns, etc.
) that runs a few dozen OSS project websites...".
Too many eggs in one basket in my opinion.
No wonder you are pissed about outages.
It sounds like you have one beefy server capable of running multiple virtualized OS instances (encrypted nonetheless).
So why not just cancel your dedicated service and get VPS from multiple providers?
That way you would have enough redundancy (e-mail, dns, rsync, HA/Varnish, whatever), none of the headaches of hardware/virtualization and save money while at it.
Managing wouldn't be harder considering your proposition of vmware/uml.
Also easier to move from your server bit by bit.
Start with DNS, then e-mail, then web, then... You can take your time as it won't cost you much upfront (zero?
) or monthly (sub $50) and gives you the ability to scale up or down the resources to acomodate the workload and cost.
2) You said "When I file 'WTF?
'-style support tickets to the provider through their web-based ticketing system"

Do you have the option to call the provider?
If not, you are doing it wrong.
From my experience, over 80\% of all ticket answers are canned responses.
If possible, try calling (if you didn't yet) and get someone that has the power to fix the issue to talk to you.
When you reach a dead end, ask to be transfered to the legal dept to discuss your contract/sla/whatever.
If they don't have one, ask where you should send the legal papers.
If everything fails, try the BBB.
Just my humble opinion.
Excuse my poor english as it's not my first language.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</id>
	<title>Re:If they do this..</title>
	<author>Anonymous</author>
	<datestamp>1261855440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>As a network admin, I've run across "I know what I'm doing" people in the past.  FWIW, I'm often times that guy when I'm calling tech support.  It's one part ego, one big part actually knowing what I'm doing.  I don't want to go through tech support 101 with some monkey on the phone when I know what the issue is.</p><p>Having said that, there have been times when I thought I knew what the issue was, but it turned out to be something else.  I think that a hosting provider wanting access to log files is perfectly reasonable.  They aren't arbitrarily asking for the files.  The questioner states that he is having problems and he asked them to sort it out.  Tech support 101 says to look at the log files.  The questioner doesn't make it clear whether or not he offered to give them the log files.</p><p>Is the hosting provider a bit off base?  Yes and no.  Yes, it's kind of lame that they are rooting boxes.  On the other hand, the questioner might be more problems than he is worth from their point of view.  If I were in the same situation, I'd just change providers and find one who will put into writing that they won't root my box (good luck with that).</p><p>(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs.  You diagnose the cause of the problem and take the car to the mechanic.  You ask the mechanic to fix your car under warranty and he asks you for your keys.  You refuse to give him the keys.</p><p>It seems to me that if a person can't fix a problem on their own, and that person then asks for help fixing the problem, they need to give up some control to the person they have asked for help from.  Unless a person selects a hosting provider with an SLA that will give them physical access to their hardware on a 24/7 basis, that person is going to have to make some accomodation (like providing access to log files) when the hosting provider needs to get involved with troubleshooting.</p></htmltext>
<tokenext>As a network admin , I 've run across " I know what I 'm doing " people in the past .
FWIW , I 'm often times that guy when I 'm calling tech support .
It 's one part ego , one big part actually knowing what I 'm doing .
I do n't want to go through tech support 101 with some monkey on the phone when I know what the issue is.Having said that , there have been times when I thought I knew what the issue was , but it turned out to be something else .
I think that a hosting provider wanting access to log files is perfectly reasonable .
They are n't arbitrarily asking for the files .
The questioner states that he is having problems and he asked them to sort it out .
Tech support 101 says to look at the log files .
The questioner does n't make it clear whether or not he offered to give them the log files.Is the hosting provider a bit off base ?
Yes and no .
Yes , it 's kind of lame that they are rooting boxes .
On the other hand , the questioner might be more problems than he is worth from their point of view .
If I were in the same situation , I 'd just change providers and find one who will put into writing that they wo n't root my box ( good luck with that ) .
( Car Analogy ) - It 's like leasing a car with a repair warranty and wanting to do your own repairs .
You diagnose the cause of the problem and take the car to the mechanic .
You ask the mechanic to fix your car under warranty and he asks you for your keys .
You refuse to give him the keys.It seems to me that if a person ca n't fix a problem on their own , and that person then asks for help fixing the problem , they need to give up some control to the person they have asked for help from .
Unless a person selects a hosting provider with an SLA that will give them physical access to their hardware on a 24/7 basis , that person is going to have to make some accomodation ( like providing access to log files ) when the hosting provider needs to get involved with troubleshooting .</tokentext>
<sentencetext>As a network admin, I've run across "I know what I'm doing" people in the past.
FWIW, I'm often times that guy when I'm calling tech support.
It's one part ego, one big part actually knowing what I'm doing.
I don't want to go through tech support 101 with some monkey on the phone when I know what the issue is.Having said that, there have been times when I thought I knew what the issue was, but it turned out to be something else.
I think that a hosting provider wanting access to log files is perfectly reasonable.
They aren't arbitrarily asking for the files.
The questioner states that he is having problems and he asked them to sort it out.
Tech support 101 says to look at the log files.
The questioner doesn't make it clear whether or not he offered to give them the log files.Is the hosting provider a bit off base?
Yes and no.
Yes, it's kind of lame that they are rooting boxes.
On the other hand, the questioner might be more problems than he is worth from their point of view.
If I were in the same situation, I'd just change providers and find one who will put into writing that they won't root my box (good luck with that).
(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs.
You diagnose the cause of the problem and take the car to the mechanic.
You ask the mechanic to fix your car under warranty and he asks you for your keys.
You refuse to give him the keys.It seems to me that if a person can't fix a problem on their own, and that person then asks for help fixing the problem, they need to give up some control to the person they have asked for help from.
Unless a person selects a hosting provider with an SLA that will give them physical access to their hardware on a 24/7 basis, that person is going to have to make some accomodation (like providing access to log files) when the hosting provider needs to get involved with troubleshooting.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30567796</id>
	<title>Re:If they do this..</title>
	<author>theNAM666</author>
	<datestamp>1261928400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Your Host's staff can read log files?  (Smile).</p><p>(About a year ago I informed a hosting company that I was turning the loglevel up,  so I could monitor what their monkeys were doing / and prove there was a disk problem on the server).</p></htmltext>
<tokenext>Your Host 's staff can read log files ?
( Smile ) . ( About a year ago I informed a hosting company that I was turning the loglevel up , so I could monitor what their monkeys were doing / and prove there was a disk problem on the server ) .</tokentext>
<sentencetext>Your Host's staff can read log files?
(Smile).(About a year ago I informed a hosting company that I was turning the loglevel up,  so I could monitor what their monkeys were doing / and prove there was a disk problem on the server).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557070</id>
	<title>You have a case</title>
	<author>Anonymous</author>
	<datestamp>1261854660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Collect all of the evidence you have, find a decent lawyer to represent you and file suit against them.<br>If you have concrete proof that they are logging into your server machine without permission, that's a serious criminal offence.</p></htmltext>
<tokenext>Collect all of the evidence you have , find a decent lawyer to represent you and file suit against them.If you have concrete proof that they are logging into your server machine without permission , that 's a serious criminal offence .</tokentext>
<sentencetext>Collect all of the evidence you have, find a decent lawyer to represent you and file suit against them.If you have concrete proof that they are logging into your server machine without permission, that's a serious criminal offence.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562448</id>
	<title>Re:If they do this..</title>
	<author>offthatop</author>
	<datestamp>1261918860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs. You diagnose the cause of the problem and take the car to the mechanic. You ask the mechanic to fix your car under warranty and he asks you for your keys. You refuse to give him the keys.</p></div><p>I'd just take it to a different mechanic.</p></div>
	</htmltext>
<tokenext>( Car Analogy ) - It 's like leasing a car with a repair warranty and wanting to do your own repairs .
You diagnose the cause of the problem and take the car to the mechanic .
You ask the mechanic to fix your car under warranty and he asks you for your keys .
You refuse to give him the keys.I 'd just take it to a different mechanic .</tokentext>
<sentencetext>(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs.
You diagnose the cause of the problem and take the car to the mechanic.
You ask the mechanic to fix your car under warranty and he asks you for your keys.
You refuse to give him the keys.I'd just take it to a different mechanic.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954</id>
	<title>Name and Shame</title>
	<author>Anonymous</author>
	<datestamp>1261853580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>If you have some reason that you haven't moved to a different provider, at least let the rest of us know who to avoid.  Name and shame, please.</p><p>As others have pointed out</p><ul>
<li>If they have physical access, you can make things a bit tougher for them, but never impossible</li>
<li>If all they wanted was access to your logs, then create a user for your providers that is in a group that can read your logs</li><li>Check with your local ISPs to see if you can get a business account (for a static IP address) and self-host.  I'm fortunate enough to have FiOS where I live, and while Verizon is really confused about having a business account at a residence, the headache is worth it.  I've got about an hour's worth of UPS at home.</li><li>At least consider the possibility that your diagnosis is wrong.  Maybe you've been rooted maliciously and not by your provider.  Or maybe what's going on is your own misconfiguration.  At least be open to this possibility (and so give them access to your logs to assist in diagnosis).</li>
<li>And, of course, consider changed providers.</li>
</ul></htmltext>
<tokenext>If you have some reason that you have n't moved to a different provider , at least let the rest of us know who to avoid .
Name and shame , please.As others have pointed out If they have physical access , you can make things a bit tougher for them , but never impossible If all they wanted was access to your logs , then create a user for your providers that is in a group that can read your logsCheck with your local ISPs to see if you can get a business account ( for a static IP address ) and self-host .
I 'm fortunate enough to have FiOS where I live , and while Verizon is really confused about having a business account at a residence , the headache is worth it .
I 've got about an hour 's worth of UPS at home.At least consider the possibility that your diagnosis is wrong .
Maybe you 've been rooted maliciously and not by your provider .
Or maybe what 's going on is your own misconfiguration .
At least be open to this possibility ( and so give them access to your logs to assist in diagnosis ) .
And , of course , consider changed providers .</tokentext>
<sentencetext>If you have some reason that you haven't moved to a different provider, at least let the rest of us know who to avoid.
Name and shame, please.As others have pointed out
If they have physical access, you can make things a bit tougher for them, but never impossible
If all they wanted was access to your logs, then create a user for your providers that is in a group that can read your logsCheck with your local ISPs to see if you can get a business account (for a static IP address) and self-host.
I'm fortunate enough to have FiOS where I live, and while Verizon is really confused about having a business account at a residence, the headache is worth it.
I've got about an hour's worth of UPS at home.At least consider the possibility that your diagnosis is wrong.
Maybe you've been rooted maliciously and not by your provider.
Or maybe what's going on is your own misconfiguration.
At least be open to this possibility (and so give them access to your logs to assist in diagnosis).
And, of course, consider changed providers.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557094</id>
	<title>Setup another box to be your log server</title>
	<author>Anonymous</author>
	<datestamp>1261854780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Several ways:<br>- Set up a NFS mount, redirect<nobr> <wbr></nobr>/var/logs to new NFS (may need some scripts to check to see if mounted if not, then change the links?)<br>- logd can write to remote servers... (not all processes use logd so this may/may not be good solution)</p><p>Then if the ISP insists, give access to that... or a copy of that...</p><p>Or just send ISP copies for requested period in question... (if not over https, then they probably could monitor everything on there side anyway)</p></htmltext>
<tokenext>Several ways : - Set up a NFS mount , redirect /var/logs to new NFS ( may need some scripts to check to see if mounted if not , then change the links ?
) - logd can write to remote servers... ( not all processes use logd so this may/may not be good solution ) Then if the ISP insists , give access to that... or a copy of that...Or just send ISP copies for requested period in question... ( if not over https , then they probably could monitor everything on there side anyway )</tokentext>
<sentencetext>Several ways:- Set up a NFS mount, redirect /var/logs to new NFS (may need some scripts to check to see if mounted if not, then change the links?
)- logd can write to remote servers... (not all processes use logd so this may/may not be good solution)Then if the ISP insists, give access to that... or a copy of that...Or just send ISP copies for requested period in question... (if not over https, then they probably could monitor everything on there side anyway)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557344</id>
	<title>Re:How do they Root your Box?</title>
	<author>Anonymous</author>
	<datestamp>1261856940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You guys optimize peoples webpages/mysql/php ? if you don't charge an arm and a leg for that, you're missing out.</p><p>Also, tech support has access to everything, even colo servers. don't think its unlikely a techie at some hosting company XYZ is downing a dedicated server to go into single user mode to reset the root pass or troubleshoot.</p><p>also, VZID = Virtuozzo, not VMware, afaik.</p></htmltext>
<tokenext>You guys optimize peoples webpages/mysql/php ?
if you do n't charge an arm and a leg for that , you 're missing out.Also , tech support has access to everything , even colo servers .
do n't think its unlikely a techie at some hosting company XYZ is downing a dedicated server to go into single user mode to reset the root pass or troubleshoot.also , VZID = Virtuozzo , not VMware , afaik .</tokentext>
<sentencetext>You guys optimize peoples webpages/mysql/php ?
if you don't charge an arm and a leg for that, you're missing out.Also, tech support has access to everything, even colo servers.
don't think its unlikely a techie at some hosting company XYZ is downing a dedicated server to go into single user mode to reset the root pass or troubleshoot.also, VZID = Virtuozzo, not VMware, afaik.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557138</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30569330</id>
	<title>Re:You're complicating things.</title>
	<author>tokul</author>
	<datestamp>1261996380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Because this server has been running 24x7 for about 3 years without a single outstanding issue. When they migrated it from Savvis to some datacenter in Dallas 2 months ago, I've had  no less than 20 separate outages , while the underlying OS and application stack itself has not changed in any way to facilitate those outages.</p></div>
</blockquote><p>Three years on one hardware is a long time. There might be a pile of dust inside that machine. Hardware might be damaged when it was moved.</p><p>You don't have memtest logs of your machine, right?</p><p>They can't help you, because you don't let them help you. Maybe you can't login only because your box sits there and asks for root password to fix disk corruption or network card is changed and host does not have working network. If you haven't pissed off them already, reasonable people might give you KVM access free of a charge. As others already pointed out, they don't need root password for logs. They don't need account for that either. You can send them packed log directory or set syslog to print logs on console.
</p><p>If you want to get your box back without giving them password, pay for KVM. Talking on slashdot won't help you.</p></div>
	</htmltext>
<tokenext>Because this server has been running 24x7 for about 3 years without a single outstanding issue .
When they migrated it from Savvis to some datacenter in Dallas 2 months ago , I 've had no less than 20 separate outages , while the underlying OS and application stack itself has not changed in any way to facilitate those outages .
Three years on one hardware is a long time .
There might be a pile of dust inside that machine .
Hardware might be damaged when it was moved.You do n't have memtest logs of your machine , right ? They ca n't help you , because you do n't let them help you .
Maybe you ca n't login only because your box sits there and asks for root password to fix disk corruption or network card is changed and host does not have working network .
If you have n't pissed off them already , reasonable people might give you KVM access free of a charge .
As others already pointed out , they do n't need root password for logs .
They do n't need account for that either .
You can send them packed log directory or set syslog to print logs on console .
If you want to get your box back without giving them password , pay for KVM .
Talking on slashdot wo n't help you .</tokentext>
<sentencetext>Because this server has been running 24x7 for about 3 years without a single outstanding issue.
When they migrated it from Savvis to some datacenter in Dallas 2 months ago, I've had  no less than 20 separate outages , while the underlying OS and application stack itself has not changed in any way to facilitate those outages.
Three years on one hardware is a long time.
There might be a pile of dust inside that machine.
Hardware might be damaged when it was moved.You don't have memtest logs of your machine, right?They can't help you, because you don't let them help you.
Maybe you can't login only because your box sits there and asks for root password to fix disk corruption or network card is changed and host does not have working network.
If you haven't pissed off them already, reasonable people might give you KVM access free of a charge.
As others already pointed out, they don't need root password for logs.
They don't need account for that either.
You can send them packed log directory or set syslog to print logs on console.
If you want to get your box back without giving them password, pay for KVM.
Talking on slashdot won't help you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559634</id>
	<title>Re:you might be our customer</title>
	<author>BitZtream</author>
	<datestamp>1261833360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just curious, which provider do you work for so everyone knows who to avoid?</p><p>I can understand not providing service to someone who is making your job impossible, locking them out of the machine?  That is unacceptable.</p><p>Our company regularly has customer who refuse to provide more info or allow us to debug our software further in their environment.  We don't turn their accounts off, we just say 'we can't help you any more because you won't help us.'  At that point they either let us, or not, and if not, we may or may not let them out of the contract.  Sometimes they can't let us help them for valid reasons, like the machine with the problem has confidential data we're not allowed to see, so we let them go if they want to.  Sometimes, if the customer isn't making any effort at all to work with us to solve the problem, we'll hold them to their contractual financial obligation.</p><p>Never, under any circumstance will we hold their data hostage.  Thats just fucking wrong asshole.</p></htmltext>
<tokenext>Just curious , which provider do you work for so everyone knows who to avoid ? I can understand not providing service to someone who is making your job impossible , locking them out of the machine ?
That is unacceptable.Our company regularly has customer who refuse to provide more info or allow us to debug our software further in their environment .
We do n't turn their accounts off , we just say 'we ca n't help you any more because you wo n't help us .
' At that point they either let us , or not , and if not , we may or may not let them out of the contract .
Sometimes they ca n't let us help them for valid reasons , like the machine with the problem has confidential data we 're not allowed to see , so we let them go if they want to .
Sometimes , if the customer is n't making any effort at all to work with us to solve the problem , we 'll hold them to their contractual financial obligation.Never , under any circumstance will we hold their data hostage .
Thats just fucking wrong asshole .</tokentext>
<sentencetext>Just curious, which provider do you work for so everyone knows who to avoid?I can understand not providing service to someone who is making your job impossible, locking them out of the machine?
That is unacceptable.Our company regularly has customer who refuse to provide more info or allow us to debug our software further in their environment.
We don't turn their accounts off, we just say 'we can't help you any more because you won't help us.
'  At that point they either let us, or not, and if not, we may or may not let them out of the contract.
Sometimes they can't let us help them for valid reasons, like the machine with the problem has confidential data we're not allowed to see, so we let them go if they want to.
Sometimes, if the customer isn't making any effort at all to work with us to solve the problem, we'll hold them to their contractual financial obligation.Never, under any circumstance will we hold their data hostage.
Thats just fucking wrong asshole.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559128</id>
	<title>Re:you might be our customer</title>
	<author>RetiredHacker</author>
	<datestamp>1261828020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So it is THEIR physical server. Post the details of your lease. I bet they get to have access how and when they wish, since it is their physical hardware. You say you have an unmanaged plan, yet you want them to help you fix your problems. Doesn't work that way. You say they found an issue with your NIC. Did they change it out? Did you ask them to?</p><p>Bottom line<nobr> <wbr></nobr>... stop whining and post ALL the information.</p></htmltext>
<tokenext>So it is THEIR physical server .
Post the details of your lease .
I bet they get to have access how and when they wish , since it is their physical hardware .
You say you have an unmanaged plan , yet you want them to help you fix your problems .
Does n't work that way .
You say they found an issue with your NIC .
Did they change it out ?
Did you ask them to ? Bottom line ... stop whining and post ALL the information .</tokentext>
<sentencetext>So it is THEIR physical server.
Post the details of your lease.
I bet they get to have access how and when they wish, since it is their physical hardware.
You say you have an unmanaged plan, yet you want them to help you fix your problems.
Doesn't work that way.
You say they found an issue with your NIC.
Did they change it out?
Did you ask them to?Bottom line ... stop whining and post ALL the information.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558928</id>
	<title>Re:If they do this..</title>
	<author>silanea</author>
	<datestamp>1261826340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>[...] If I were a provider, I might even insist upon the ability to access systems running on my network simply because of liability concerns as the provider. I as the provider can't be allowing untoward activity on my network. [...]</p></div><p>You do not need any access to a customer's box to stop any illegal behaviour other than a way to yank the network cable from it. Access equals liability.</p></div>
	</htmltext>
<tokenext>[ ... ] If I were a provider , I might even insist upon the ability to access systems running on my network simply because of liability concerns as the provider .
I as the provider ca n't be allowing untoward activity on my network .
[ ... ] You do not need any access to a customer 's box to stop any illegal behaviour other than a way to yank the network cable from it .
Access equals liability .</tokentext>
<sentencetext>[...] If I were a provider, I might even insist upon the ability to access systems running on my network simply because of liability concerns as the provider.
I as the provider can't be allowing untoward activity on my network.
[...]You do not need any access to a customer's box to stop any illegal behaviour other than a way to yank the network cable from it.
Access equals liability.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558914</id>
	<title>Re:More details please?</title>
	<author>NormalVisual</author>
	<datestamp>1261826220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>We also kept root ssh keys to all of the servers just in case someone wanted to try and be a dick about it.</i> <br> <br>

"PermitRootLogin=0", anyone?</htmltext>
<tokenext>We also kept root ssh keys to all of the servers just in case someone wanted to try and be a dick about it .
" PermitRootLogin = 0 " , anyone ?</tokentext>
<sentencetext>We also kept root ssh keys to all of the servers just in case someone wanted to try and be a dick about it.
"PermitRootLogin=0", anyone?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556962</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557864</id>
	<title>Hardware server, BIOS password</title>
	<author>Anonymous</author>
	<datestamp>1261818000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You need your own hardware, remote KVM access, and to set a BIOS password. There are ways to break BIOS passwords, but your average "I'm smarter than \_you\_" hosting employee will not know how.</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; Set the boot loader password.<br>
&nbsp; &nbsp; &nbsp; &nbsp; Set the boot order to exclude anything but what you want to permit to boot.<br>
&nbsp; &nbsp; &nbsp; &nbsp; Set the BIOS password.</p><p>Note that if it's a virtualized server, you're pretty much out of luck. But those steps will help prevent problems with boot manipulation.</p></htmltext>
<tokenext>You need your own hardware , remote KVM access , and to set a BIOS password .
There are ways to break BIOS passwords , but your average " I 'm smarter than \ _you \ _ " hosting employee will not know how .
        Set the boot loader password .
        Set the boot order to exclude anything but what you want to permit to boot .
        Set the BIOS password.Note that if it 's a virtualized server , you 're pretty much out of luck .
But those steps will help prevent problems with boot manipulation .</tokentext>
<sentencetext>You need your own hardware, remote KVM access, and to set a BIOS password.
There are ways to break BIOS passwords, but your average "I'm smarter than \_you\_" hosting employee will not know how.
        Set the boot loader password.
        Set the boot order to exclude anything but what you want to permit to boot.
        Set the BIOS password.Note that if it's a virtualized server, you're pretty much out of luck.
But those steps will help prevent problems with boot manipulation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556794</id>
	<title>Re:If they do this..</title>
	<author>erpbridge</author>
	<datestamp>1261852320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I agree. This provider sounds very fishy, if they are intentionally breaking into your hardware without your permission. Get another provider, post haste, that has a privacy clause in their contract guaranteeing that they will not do such a thing without your explicit permission, and that if they do something outside the contract such as breaking into your box without your permission, there's a rather steep monetary fee to pay on their part as a breach of contract lawsuit is in order.</p></htmltext>
<tokenext>I agree .
This provider sounds very fishy , if they are intentionally breaking into your hardware without your permission .
Get another provider , post haste , that has a privacy clause in their contract guaranteeing that they will not do such a thing without your explicit permission , and that if they do something outside the contract such as breaking into your box without your permission , there 's a rather steep monetary fee to pay on their part as a breach of contract lawsuit is in order .</tokentext>
<sentencetext>I agree.
This provider sounds very fishy, if they are intentionally breaking into your hardware without your permission.
Get another provider, post haste, that has a privacy clause in their contract guaranteeing that they will not do such a thing without your explicit permission, and that if they do something outside the contract such as breaking into your box without your permission, there's a rather steep monetary fee to pay on their part as a breach of contract lawsuit is in order.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558970</id>
	<title>A workaround.</title>
	<author>Random Data</author>
	<datestamp>1261826640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yes, I know you've had a zillion "Set up a user with log access". I also saw the comment where you're currently locked out, so I support the suggestion that you tell your host to FOAD.

But if you're in a situation like this there's nothing stopping you renaming the root account and creating a new "root" with a UID other than 0 and giving that *some* rights. You can even say with a straight face that they've got the "root" password. I tend not to bother on my home boxes (as often as not OS X these days anyway), but when I was adminning Windows I'd tend to rename the guest account to administrator and have another name for the real admin account. Similar tricks have been done on Linux boxes.</htmltext>
<tokenext>Yes , I know you 've had a zillion " Set up a user with log access " .
I also saw the comment where you 're currently locked out , so I support the suggestion that you tell your host to FOAD .
But if you 're in a situation like this there 's nothing stopping you renaming the root account and creating a new " root " with a UID other than 0 and giving that * some * rights .
You can even say with a straight face that they 've got the " root " password .
I tend not to bother on my home boxes ( as often as not OS X these days anyway ) , but when I was adminning Windows I 'd tend to rename the guest account to administrator and have another name for the real admin account .
Similar tricks have been done on Linux boxes .</tokentext>
<sentencetext>Yes, I know you've had a zillion "Set up a user with log access".
I also saw the comment where you're currently locked out, so I support the suggestion that you tell your host to FOAD.
But if you're in a situation like this there's nothing stopping you renaming the root account and creating a new "root" with a UID other than 0 and giving that *some* rights.
You can even say with a straight face that they've got the "root" password.
I tend not to bother on my home boxes (as often as not OS X these days anyway), but when I was adminning Windows I'd tend to rename the guest account to administrator and have another name for the real admin account.
Similar tricks have been done on Linux boxes.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557032</id>
	<title>Password-protect GRUB, Access card, new ISP</title>
	<author>Anonymous</author>
	<datestamp>1261854180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's all you need.</p><p>First, if you don't have physical access to the server, you always password-protect grub, encrypt important directories, and have an access card + watchdog connected.<br>With the passprotected GRUB they won't be able to just pass init=/bin/bash or similar to bypass your login.<br>The encrypted directories will keep your data safe in case the worst happens and someone boots your machine through a USB/CD/etc. If you provided your own hardware for this, or can access the server locally at any time, go there and do this:<br>
&nbsp; &nbsp; - Disable booting from devices other than your main drive, disable legacy usb support, only enable the SATA/SCSI/IDE port you are using.<br>
&nbsp; &nbsp; - Password protect the BIOS<br>
&nbsp; &nbsp; - Use a glue gun to cover the Motherboard's internal battery and the Jumpers to clear CMOS ( So they can't just erase that and access your bios again )<br>
&nbsp; &nbsp; - Put some  warranty-style stickers so you know if someone opens your case.<br>Your access card and watchdog will let you do everything you need yourself.<br>Finally, get an collocation provider that doesn't suck.</p><p>Also, post that ISP's name so we never do business with them.</p></htmltext>
<tokenext>That 's all you need.First , if you do n't have physical access to the server , you always password-protect grub , encrypt important directories , and have an access card + watchdog connected.With the passprotected GRUB they wo n't be able to just pass init = /bin/bash or similar to bypass your login.The encrypted directories will keep your data safe in case the worst happens and someone boots your machine through a USB/CD/etc .
If you provided your own hardware for this , or can access the server locally at any time , go there and do this :     - Disable booting from devices other than your main drive , disable legacy usb support , only enable the SATA/SCSI/IDE port you are using .
    - Password protect the BIOS     - Use a glue gun to cover the Motherboard 's internal battery and the Jumpers to clear CMOS ( So they ca n't just erase that and access your bios again )     - Put some warranty-style stickers so you know if someone opens your case.Your access card and watchdog will let you do everything you need yourself.Finally , get an collocation provider that does n't suck.Also , post that ISP 's name so we never do business with them .</tokentext>
<sentencetext>That's all you need.First, if you don't have physical access to the server, you always password-protect grub, encrypt important directories, and have an access card + watchdog connected.With the passprotected GRUB they won't be able to just pass init=/bin/bash or similar to bypass your login.The encrypted directories will keep your data safe in case the worst happens and someone boots your machine through a USB/CD/etc.
If you provided your own hardware for this, or can access the server locally at any time, go there and do this:
    - Disable booting from devices other than your main drive, disable legacy usb support, only enable the SATA/SCSI/IDE port you are using.
    - Password protect the BIOS
    - Use a glue gun to cover the Motherboard's internal battery and the Jumpers to clear CMOS ( So they can't just erase that and access your bios again )
    - Put some  warranty-style stickers so you know if someone opens your case.Your access card and watchdog will let you do everything you need yourself.Finally, get an collocation provider that doesn't suck.Also, post that ISP's name so we never do business with them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556896</id>
	<title>Irony...</title>
	<author>Anonymous</author>
	<datestamp>1261852980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>You call yourself "hacker" but you don't already know how to do this.</p></htmltext>
<tokenext>You call yourself " hacker " but you do n't already know how to do this .</tokentext>
<sentencetext>You call yourself "hacker" but you don't already know how to do this.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557520</id>
	<title>I had the same situation..</title>
	<author>ECXStar</author>
	<datestamp>1261858500000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>I host with Softlayer.net (dedicated boxes) and I had the same mysterious issues, server going offline and coming back on. I have a different approach.  I trust the techs of the company I'm hosting with so I don't mind giving up root access to chase this problem down.  What I do after that is change the root pass again and I'm done.

What I'm finding is when the OS and logs come back clean, the problem is mostly likely tied to a DC router issue (a bug or misconfiguration).  That's exactly what the excellent techs at SL found.  They even filed an RFO (reason for outage) report several days later explaining the problem in detail.

So, just like everyone here says, get with a good hosting company and put some trust in the support staff.  I used to think that all these companies were about the same level of service if your on a dedicated but, I soon found out you really do get what you pay for.</htmltext>
<tokenext>I host with Softlayer.net ( dedicated boxes ) and I had the same mysterious issues , server going offline and coming back on .
I have a different approach .
I trust the techs of the company I 'm hosting with so I do n't mind giving up root access to chase this problem down .
What I do after that is change the root pass again and I 'm done .
What I 'm finding is when the OS and logs come back clean , the problem is mostly likely tied to a DC router issue ( a bug or misconfiguration ) .
That 's exactly what the excellent techs at SL found .
They even filed an RFO ( reason for outage ) report several days later explaining the problem in detail .
So , just like everyone here says , get with a good hosting company and put some trust in the support staff .
I used to think that all these companies were about the same level of service if your on a dedicated but , I soon found out you really do get what you pay for .</tokentext>
<sentencetext>I host with Softlayer.net (dedicated boxes) and I had the same mysterious issues, server going offline and coming back on.
I have a different approach.
I trust the techs of the company I'm hosting with so I don't mind giving up root access to chase this problem down.
What I do after that is change the root pass again and I'm done.
What I'm finding is when the OS and logs come back clean, the problem is mostly likely tied to a DC router issue (a bug or misconfiguration).
That's exactly what the excellent techs at SL found.
They even filed an RFO (reason for outage) report several days later explaining the problem in detail.
So, just like everyone here says, get with a good hosting company and put some trust in the support staff.
I used to think that all these companies were about the same level of service if your on a dedicated but, I soon found out you really do get what you pay for.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557828</id>
	<title>Re:You're complicating things.</title>
	<author>casualsax3</author>
	<datestamp>1261860900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>They offer KVM access, at $35.00/day, which in this case I refuse to pay to fix what they broke, outside of the context of the server.</p></div><p>Stop being stubborn - why not KVM in, prove it's their fault, and then make them reimburse you for it?</p><p><div class="quote"><p>Alternately, they want me to hand over the root password (not a privileged account, but THE root password), so they can do it themselves.</p></div><p>Sounds like you're either incapable or unwilling to fix the problem yourself, but at the same time you refuse to let them do it?  What exactly would make you happy here?  And don't say "moving me back to the old hardware and datacenter that I was paying for!"  Be realistic.</p><p><div class="quote"><p>Only a few days ago, they indicated that the NIC on the server may be causing the issues. I'm down 2-3 hours every other Sunday because of this.</p></div><p>You said yourself that it's new hardware.  It's completely reasonable for them to suggest you've got a bad NIC driver in there for whatever card you were moved to.</p><p><nobr> <wbr></nobr></p><div class="quote"><p>...every other Sunday between 7:00am and 8:00am EST, my server's load goes over 100 as incoming connections spike over 700/sec., sendmail refuses connections due to the load, and the box seizes up. The logs show that the connections are established and then hang.</p></div><p>This is almost certainly a problem on the system itself.  I've seen a handful of cases where hardware load balancers in DSR mode can lead to connection pileups under certain conditions, but 99\% of the time it's a problem on the server itself.  In any event, tuning should be able to prevent that from knocking the box over completely, allowing you to stay logged in and see what's going on.
</p><p>
Also, by claiming that nothing has changed on the system, you're either lying, or you're a horrible sysadmin who doesn't apply updates.  Another potential scenario I see here (obviously aside from new hardware using previously unused drivers...) is that you or your package management system installed a new kernel or NIC driver, but never rebooted.  Then when the server was powered off and migrated to the new facility, it came back up with the new (and potentially problematic) driver/kernel.</p></div>
	</htmltext>
<tokenext>They offer KVM access , at $ 35.00/day , which in this case I refuse to pay to fix what they broke , outside of the context of the server.Stop being stubborn - why not KVM in , prove it 's their fault , and then make them reimburse you for it ? Alternately , they want me to hand over the root password ( not a privileged account , but THE root password ) , so they can do it themselves.Sounds like you 're either incapable or unwilling to fix the problem yourself , but at the same time you refuse to let them do it ?
What exactly would make you happy here ?
And do n't say " moving me back to the old hardware and datacenter that I was paying for !
" Be realistic.Only a few days ago , they indicated that the NIC on the server may be causing the issues .
I 'm down 2-3 hours every other Sunday because of this.You said yourself that it 's new hardware .
It 's completely reasonable for them to suggest you 've got a bad NIC driver in there for whatever card you were moved to .
...every other Sunday between 7 : 00am and 8 : 00am EST , my server 's load goes over 100 as incoming connections spike over 700/sec. , sendmail refuses connections due to the load , and the box seizes up .
The logs show that the connections are established and then hang.This is almost certainly a problem on the system itself .
I 've seen a handful of cases where hardware load balancers in DSR mode can lead to connection pileups under certain conditions , but 99 \ % of the time it 's a problem on the server itself .
In any event , tuning should be able to prevent that from knocking the box over completely , allowing you to stay logged in and see what 's going on .
Also , by claiming that nothing has changed on the system , you 're either lying , or you 're a horrible sysadmin who does n't apply updates .
Another potential scenario I see here ( obviously aside from new hardware using previously unused drivers... ) is that you or your package management system installed a new kernel or NIC driver , but never rebooted .
Then when the server was powered off and migrated to the new facility , it came back up with the new ( and potentially problematic ) driver/kernel .</tokentext>
<sentencetext>They offer KVM access, at $35.00/day, which in this case I refuse to pay to fix what they broke, outside of the context of the server.Stop being stubborn - why not KVM in, prove it's their fault, and then make them reimburse you for it?Alternately, they want me to hand over the root password (not a privileged account, but THE root password), so they can do it themselves.Sounds like you're either incapable or unwilling to fix the problem yourself, but at the same time you refuse to let them do it?
What exactly would make you happy here?
And don't say "moving me back to the old hardware and datacenter that I was paying for!
"  Be realistic.Only a few days ago, they indicated that the NIC on the server may be causing the issues.
I'm down 2-3 hours every other Sunday because of this.You said yourself that it's new hardware.
It's completely reasonable for them to suggest you've got a bad NIC driver in there for whatever card you were moved to.
...every other Sunday between 7:00am and 8:00am EST, my server's load goes over 100 as incoming connections spike over 700/sec., sendmail refuses connections due to the load, and the box seizes up.
The logs show that the connections are established and then hang.This is almost certainly a problem on the system itself.
I've seen a handful of cases where hardware load balancers in DSR mode can lead to connection pileups under certain conditions, but 99\% of the time it's a problem on the server itself.
In any event, tuning should be able to prevent that from knocking the box over completely, allowing you to stay logged in and see what's going on.
Also, by claiming that nothing has changed on the system, you're either lying, or you're a horrible sysadmin who doesn't apply updates.
Another potential scenario I see here (obviously aside from new hardware using previously unused drivers...) is that you or your package management system installed a new kernel or NIC driver, but never rebooted.
Then when the server was powered off and migrated to the new facility, it came back up with the new (and potentially problematic) driver/kernel.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559440</id>
	<title>Re:Tough question...</title>
	<author>Anonymous</author>
	<datestamp>1261831020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My hat's off to you couchslug. Genius analogy.</p></htmltext>
<tokenext>My hat 's off to you couchslug .
Genius analogy .</tokentext>
<sentencetext>My hat's off to you couchslug.
Genius analogy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557636</id>
	<title>Re:If they do this..</title>
	<author>wytcld</author>
	<datestamp>1261859460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>If your hosting provider wants the log files, they don't need root, just a copy of the files. Give them a user-level login, and put a copy of the files where that user can see them.</p><p>The outage already happened, right? They don't need the current logs as they happen, just the logs for the outage period.</p></htmltext>
<tokenext>If your hosting provider wants the log files , they do n't need root , just a copy of the files .
Give them a user-level login , and put a copy of the files where that user can see them.The outage already happened , right ?
They do n't need the current logs as they happen , just the logs for the outage period .</tokentext>
<sentencetext>If your hosting provider wants the log files, they don't need root, just a copy of the files.
Give them a user-level login, and put a copy of the files where that user can see them.The outage already happened, right?
They don't need the current logs as they happen, just the logs for the outage period.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557066</id>
	<title>What did you expect?</title>
	<author>Anonymous</author>
	<datestamp>1261854660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Did you read the fine print? Basically, you don't "have" anything. You are using their server(s), at their location, and your access is dependent solely upon their discretion. It's always been a known fact that if a third party has access to your physical, or in this case, virtual server, they OWN you. No amount of encryption/passwords/prayer will improve your privacy. It doesn't matter what you do, since they have physical access to the servers, you'll never be secure, you'll never have exclusive access to your "server", and you'll always wonder what they are doing.</p><p>Face it, to get what you want, you're going to need to setup your own server(s), behind your own firewall(s), and get a good nights sleep. You'll still have concerns to worry about, but you'll be the one in the driver's seat.</p></htmltext>
<tokenext>Did you read the fine print ?
Basically , you do n't " have " anything .
You are using their server ( s ) , at their location , and your access is dependent solely upon their discretion .
It 's always been a known fact that if a third party has access to your physical , or in this case , virtual server , they OWN you .
No amount of encryption/passwords/prayer will improve your privacy .
It does n't matter what you do , since they have physical access to the servers , you 'll never be secure , you 'll never have exclusive access to your " server " , and you 'll always wonder what they are doing.Face it , to get what you want , you 're going to need to setup your own server ( s ) , behind your own firewall ( s ) , and get a good nights sleep .
You 'll still have concerns to worry about , but you 'll be the one in the driver 's seat .</tokentext>
<sentencetext>Did you read the fine print?
Basically, you don't "have" anything.
You are using their server(s), at their location, and your access is dependent solely upon their discretion.
It's always been a known fact that if a third party has access to your physical, or in this case, virtual server, they OWN you.
No amount of encryption/passwords/prayer will improve your privacy.
It doesn't matter what you do, since they have physical access to the servers, you'll never be secure, you'll never have exclusive access to your "server", and you'll always wonder what they are doing.Face it, to get what you want, you're going to need to setup your own server(s), behind your own firewall(s), and get a good nights sleep.
You'll still have concerns to worry about, but you'll be the one in the driver's seat.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30566094</id>
	<title>Re:If they do this..</title>
	<author>clanrat</author>
	<datestamp>1261912980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs.  You diagnose the cause of the problem and take the car to the mechanic.  You ask the mechanic to fix your car under warranty and he asks you for your keys.  You refuse to give him the keys.</p></div><p>I find your analogy to be somewhat flawed. A better analogy would be like the city or municipality forcing your car open when you don't hand over the keys after you've called to have your street repaired.</p></div>
	</htmltext>
<tokenext>( Car Analogy ) - It 's like leasing a car with a repair warranty and wanting to do your own repairs .
You diagnose the cause of the problem and take the car to the mechanic .
You ask the mechanic to fix your car under warranty and he asks you for your keys .
You refuse to give him the keys.I find your analogy to be somewhat flawed .
A better analogy would be like the city or municipality forcing your car open when you do n't hand over the keys after you 've called to have your street repaired .</tokentext>
<sentencetext>(Car Analogy) - It's like leasing a car with a repair warranty and wanting to do your own repairs.
You diagnose the cause of the problem and take the car to the mechanic.
You ask the mechanic to fix your car under warranty and he asks you for your keys.
You refuse to give him the keys.I find your analogy to be somewhat flawed.
A better analogy would be like the city or municipality forcing your car open when you don't hand over the keys after you've called to have your street repaired.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557302</id>
	<title>Re:Stop being a douche</title>
	<author>Anonymous</author>
	<datestamp>1261856640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I wouldn't give them an account with sudo. A non-privileged account should be enough, if they really need root, share a screen session with them, so you can see everything they do, and interfere with anything you don't like.</htmltext>
<tokenext>I would n't give them an account with sudo .
A non-privileged account should be enough , if they really need root , share a screen session with them , so you can see everything they do , and interfere with anything you do n't like .</tokentext>
<sentencetext>I wouldn't give them an account with sudo.
A non-privileged account should be enough, if they really need root, share a screen session with them, so you can see everything they do, and interfere with anything you don't like.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30586644</id>
	<title>Re:Tough question...</title>
	<author>jimicus</author>
	<datestamp>1262081700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No, you can solve that problem with a fairly simple ceremony.</p><p>Though it usually winds up becoming an all-day affair involving elderly relatives that you haven't seen in twenty years because you can't stand the sight of them.</p></htmltext>
<tokenext>No , you can solve that problem with a fairly simple ceremony.Though it usually winds up becoming an all-day affair involving elderly relatives that you have n't seen in twenty years because you ca n't stand the sight of them .</tokentext>
<sentencetext>No, you can solve that problem with a fairly simple ceremony.Though it usually winds up becoming an all-day affair involving elderly relatives that you haven't seen in twenty years because you can't stand the sight of them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560776</id>
	<title>dummification</title>
	<author>Anonymous</author>
	<datestamp>1261849680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>ok..lets say you rent an apartment..and the of you your apartment is leaking...and you are not home...the owner  of the property can go to your apartment and fix it and leave a note just as a COURTESY..and you can't do jack about it....they can't take anything..but they can even break the door and walk in...sorry if I had to dummyfy the issue so you understand...</p></htmltext>
<tokenext>ok..lets say you rent an apartment..and the of you your apartment is leaking...and you are not home...the owner of the property can go to your apartment and fix it and leave a note just as a COURTESY..and you ca n't do jack about it....they ca n't take anything..but they can even break the door and walk in...sorry if I had to dummyfy the issue so you understand.. .</tokentext>
<sentencetext>ok..lets say you rent an apartment..and the of you your apartment is leaking...and you are not home...the owner  of the property can go to your apartment and fix it and leave a note just as a COURTESY..and you can't do jack about it....they can't take anything..but they can even break the door and walk in...sorry if I had to dummyfy the issue so you understand...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561518</id>
	<title>Re:Name and Shame</title>
	<author>Anonymous</author>
	<datestamp>1261904580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><a href="http://ask.slashdot.org/comments.pl?sid=1490392&amp;cid=30557506" title="slashdot.org" rel="nofollow">They offer KVM access, at $35.00/day</a> [slashdot.org] and have a data center in Dallas. Surely we can figure out who they are.

<a href="http://iweb.com/dedicated/budget-servers/features/" title="iweb.com" rel="nofollow">iWeb</a> [iweb.com] charges $35 for Emergency KVM over IP access but they also offer Free 1-day on demand KVM over IP access. <a href="http://www.maxnoc.com/managed-services/deployment/ip-kvm.html" title="maxnoc.com" rel="nofollow">MaxNOC</a> [maxnoc.com] charges $40 for anytime access IP KVM and $35 for 24 hour temporary access but they don't seem to have a Dallas data center.
<a href="http://ask.slashdot.org/comments.pl?sid=1490392&amp;cid=30558176" title="slashdot.org" rel="nofollow">Another poster</a> [slashdot.org] says it's <a href="http://www.layeredtech.com/" title="layeredtech.com" rel="nofollow">Layered Tech</a> [layeredtech.com] but I can't find any useful information on their website to verify.</htmltext>
<tokenext>They offer KVM access , at $ 35.00/day [ slashdot.org ] and have a data center in Dallas .
Surely we can figure out who they are .
iWeb [ iweb.com ] charges $ 35 for Emergency KVM over IP access but they also offer Free 1-day on demand KVM over IP access .
MaxNOC [ maxnoc.com ] charges $ 40 for anytime access IP KVM and $ 35 for 24 hour temporary access but they do n't seem to have a Dallas data center .
Another poster [ slashdot.org ] says it 's Layered Tech [ layeredtech.com ] but I ca n't find any useful information on their website to verify .</tokentext>
<sentencetext>They offer KVM access, at $35.00/day [slashdot.org] and have a data center in Dallas.
Surely we can figure out who they are.
iWeb [iweb.com] charges $35 for Emergency KVM over IP access but they also offer Free 1-day on demand KVM over IP access.
MaxNOC [maxnoc.com] charges $40 for anytime access IP KVM and $35 for 24 hour temporary access but they don't seem to have a Dallas data center.
Another poster [slashdot.org] says it's Layered Tech [layeredtech.com] but I can't find any useful information on their website to verify.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830</id>
	<title>Re:If they do this..</title>
	<author>Anonymous</author>
	<datestamp>1261852560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>Have them charged with illegally accessing your machine. Add in a claim for damages for the costs and time that is necessary to get the computer up and running again.</p><p>It may be a little harsh, but your Attorney General cannot refuse to prosecute this, as it would set a precedent. Any refusal to prosecute, would allow for a lawsuit of selective enforcement of the law.</p><p>You'll probably have your ISP booting you as a customer, but it sounds like you don't really want them anyway.</p></htmltext>
<tokenext>Have them charged with illegally accessing your machine .
Add in a claim for damages for the costs and time that is necessary to get the computer up and running again.It may be a little harsh , but your Attorney General can not refuse to prosecute this , as it would set a precedent .
Any refusal to prosecute , would allow for a lawsuit of selective enforcement of the law.You 'll probably have your ISP booting you as a customer , but it sounds like you do n't really want them anyway .</tokentext>
<sentencetext>Have them charged with illegally accessing your machine.
Add in a claim for damages for the costs and time that is necessary to get the computer up and running again.It may be a little harsh, but your Attorney General cannot refuse to prosecute this, as it would set a precedent.
Any refusal to prosecute, would allow for a lawsuit of selective enforcement of the law.You'll probably have your ISP booting you as a customer, but it sounds like you don't really want them anyway.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556934</id>
	<title>Dell Drac</title>
	<author>ulzeraj</author>
	<datestamp>1261853340000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Password on GRUB will not protect against physical access to a machine. Maybe the best thing you can do is to encrypt the disks. And for now on try to get servers with Drac <a href="http://en.wikipedia.org/wiki/Dell\_DRAC" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/Dell\_DRAC</a> [wikipedia.org] or something similar installed. Through Drac's remote console you can remotely access the computer during boot process as if you were sitting at the local console.</htmltext>
<tokenext>Password on GRUB will not protect against physical access to a machine .
Maybe the best thing you can do is to encrypt the disks .
And for now on try to get servers with Drac http : //en.wikipedia.org/wiki/Dell \ _DRAC [ wikipedia.org ] or something similar installed .
Through Drac 's remote console you can remotely access the computer during boot process as if you were sitting at the local console .</tokentext>
<sentencetext>Password on GRUB will not protect against physical access to a machine.
Maybe the best thing you can do is to encrypt the disks.
And for now on try to get servers with Drac http://en.wikipedia.org/wiki/Dell\_DRAC [wikipedia.org] or something similar installed.
Through Drac's remote console you can remotely access the computer during boot process as if you were sitting at the local console.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557018</id>
	<title>Yubikey and YubiPAM</title>
	<author>strredwolf</author>
	<datestamp>1261854060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Simple:</p><p>1. Require all passwords to be Yubikey OTP passwords on any login prompt.<br>2. Refuse access, and only give them the logs manually.<br>3. When they shut your server down and open it up to yank the drive, hit 'em with a breach of lawsuit.<br>4. ????<br>5. PROFIT!</p></htmltext>
<tokenext>Simple : 1 .
Require all passwords to be Yubikey OTP passwords on any login prompt.2 .
Refuse access , and only give them the logs manually.3 .
When they shut your server down and open it up to yank the drive , hit 'em with a breach of lawsuit.4 .
? ? ? ? 5. PROFIT !</tokentext>
<sentencetext>Simple:1.
Require all passwords to be Yubikey OTP passwords on any login prompt.2.
Refuse access, and only give them the logs manually.3.
When they shut your server down and open it up to yank the drive, hit 'em with a breach of lawsuit.4.
????5. PROFIT!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560464</id>
	<title>authorized\_keys2</title>
	<author>Anonymous</author>
	<datestamp>1261845420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My provider (OVH) has root access to my dedicated box via ssh.</p><p>Preconfigured linux images have ssh keyfiles (google: authorized\_keys2) set up. This is also public information. This is also easy to  disable.</p><p>I'ts hard to believe any provider would go through the trouble checking logs the hard way if client doesn't want to give root when asked.</p></htmltext>
<tokenext>My provider ( OVH ) has root access to my dedicated box via ssh.Preconfigured linux images have ssh keyfiles ( google : authorized \ _keys2 ) set up .
This is also public information .
This is also easy to disable.I'ts hard to believe any provider would go through the trouble checking logs the hard way if client does n't want to give root when asked .</tokentext>
<sentencetext>My provider (OVH) has root access to my dedicated box via ssh.Preconfigured linux images have ssh keyfiles (google: authorized\_keys2) set up.
This is also public information.
This is also easy to  disable.I'ts hard to believe any provider would go through the trouble checking logs the hard way if client doesn't want to give root when asked.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560450</id>
	<title>Re:Name and Shame</title>
	<author>GPLHost-Thomas</author>
	<datestamp>1261845300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>Check with your local ISPs to see if you can get a business account (for a static IP address) and self-host. I'm fortunate enough to have FiOS where I live, and while Verizon is really confused about having a business account at a residence, the headache is worth it. I've got about an hour's worth of UPS at home.</i> <br>
With that, did you install:<ul> <li>Fire detection and prevention (with a gas like FM2000)</li><li>A big heavy door to avoid any access</li><li>Anti-static electrical installation</li><li>An employee that can access your server and replace parts (that you'd have in stock) when you go in holiday</li></ul><p>

If you didn't then that's not up to the level of ANY decent data center. Plus the cost of electricity AND a dedicated leased line with big bandwidth up and down makes it most of the time not worth the money compared to hosting in a data center, and often very dangerous (electric fire is the most important). Hosting ONE server at home is NEVER economical AND safe (you barely can have one of the 2, and most of the time none of them).</p></htmltext>
<tokenext>Check with your local ISPs to see if you can get a business account ( for a static IP address ) and self-host .
I 'm fortunate enough to have FiOS where I live , and while Verizon is really confused about having a business account at a residence , the headache is worth it .
I 've got about an hour 's worth of UPS at home .
With that , did you install : Fire detection and prevention ( with a gas like FM2000 ) A big heavy door to avoid any accessAnti-static electrical installationAn employee that can access your server and replace parts ( that you 'd have in stock ) when you go in holiday If you did n't then that 's not up to the level of ANY decent data center .
Plus the cost of electricity AND a dedicated leased line with big bandwidth up and down makes it most of the time not worth the money compared to hosting in a data center , and often very dangerous ( electric fire is the most important ) .
Hosting ONE server at home is NEVER economical AND safe ( you barely can have one of the 2 , and most of the time none of them ) .</tokentext>
<sentencetext>Check with your local ISPs to see if you can get a business account (for a static IP address) and self-host.
I'm fortunate enough to have FiOS where I live, and while Verizon is really confused about having a business account at a residence, the headache is worth it.
I've got about an hour's worth of UPS at home.
With that, did you install: Fire detection and prevention (with a gas like FM2000)A big heavy door to avoid any accessAnti-static electrical installationAn employee that can access your server and replace parts (that you'd have in stock) when you go in holiday

If you didn't then that's not up to the level of ANY decent data center.
Plus the cost of electricity AND a dedicated leased line with big bandwidth up and down makes it most of the time not worth the money compared to hosting in a data center, and often very dangerous (electric fire is the most important).
Hosting ONE server at home is NEVER economical AND safe (you barely can have one of the 2, and most of the time none of them).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557482</id>
	<title>Midiclorians going down</title>
	<author>Anonymous</author>
	<datestamp>1261858080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>No wonder my midiclorians are going down!  I can barely make sense of the world now...</p></htmltext>
<tokenext>No wonder my midiclorians are going down !
I can barely make sense of the world now.. .</tokentext>
<sentencetext>No wonder my midiclorians are going down!
I can barely make sense of the world now...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557584</id>
	<title>Missing the boat...no security in hosted env</title>
	<author>Anonymous</author>
	<datestamp>1261859160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's their equipment. Forgetting about ethics and due process and legal agreements for the moment, the very fact that it<br>is their equipment and they have physical access, you cannot secure your platform against them.<br>All your talk about encryption is moot. Learn that fact now.</p><p>Your solutions are either to</p><ul><li>consider that you may have made a mistake and it's the box/applications that are the problem, and that they have<br>good reason to suspect this, hence have accessed your platform on multiple occasions; (option - work with them or fix your own problem)</li><li>conclude they are not behaving ethically and/or have a non-robust network environment (option - switch providers)</li><li>conclude that security is important to you, and don't use a hosting provider. Co-lo the box in a physical environment that<br>caters to folks with these kinds of needs. That either means using a co-location provider and ponying up for rack space,<br>or locating it in your home/office.</li></ul></htmltext>
<tokenext>It 's their equipment .
Forgetting about ethics and due process and legal agreements for the moment , the very fact that itis their equipment and they have physical access , you can not secure your platform against them.All your talk about encryption is moot .
Learn that fact now.Your solutions are either toconsider that you may have made a mistake and it 's the box/applications that are the problem , and that they havegood reason to suspect this , hence have accessed your platform on multiple occasions ; ( option - work with them or fix your own problem ) conclude they are not behaving ethically and/or have a non-robust network environment ( option - switch providers ) conclude that security is important to you , and do n't use a hosting provider .
Co-lo the box in a physical environment thatcaters to folks with these kinds of needs .
That either means using a co-location provider and ponying up for rack space,or locating it in your home/office .</tokentext>
<sentencetext>It's their equipment.
Forgetting about ethics and due process and legal agreements for the moment, the very fact that itis their equipment and they have physical access, you cannot secure your platform against them.All your talk about encryption is moot.
Learn that fact now.Your solutions are either toconsider that you may have made a mistake and it's the box/applications that are the problem, and that they havegood reason to suspect this, hence have accessed your platform on multiple occasions; (option - work with them or fix your own problem)conclude they are not behaving ethically and/or have a non-robust network environment (option - switch providers)conclude that security is important to you, and don't use a hosting provider.
Co-lo the box in a physical environment thatcaters to folks with these kinds of needs.
That either means using a co-location provider and ponying up for rack space,or locating it in your home/office.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560896</id>
	<title>This "hacker" guy.</title>
	<author>Anonymous</author>
	<datestamp>1261851420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>This "hacker" guy is actually causing a bit of a stir on the Drobo forums, accusing support left-right-and-centre of destroying his data. Only a couple of days before he started screaming bloody murder he was posting questions about "tuning" his filesystems with tune2fs.</p><p>Shame the Drobo forums are for customers only, but he's a bit of a tit. I wouldn't believe a single word he says about the ISP.</p></htmltext>
<tokenext>This " hacker " guy is actually causing a bit of a stir on the Drobo forums , accusing support left-right-and-centre of destroying his data .
Only a couple of days before he started screaming bloody murder he was posting questions about " tuning " his filesystems with tune2fs.Shame the Drobo forums are for customers only , but he 's a bit of a tit .
I would n't believe a single word he says about the ISP .</tokentext>
<sentencetext>This "hacker" guy is actually causing a bit of a stir on the Drobo forums, accusing support left-right-and-centre of destroying his data.
Only a couple of days before he started screaming bloody murder he was posting questions about "tuning" his filesystems with tune2fs.Shame the Drobo forums are for customers only, but he's a bit of a tit.
I wouldn't believe a single word he says about the ISP.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557170</id>
	<title>Shutting you down to investigate your spamming</title>
	<author>Culture20</author>
	<datestamp>1261855500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Just stop Spamming, and they'll stop rooting you.  And don't ask us how to prevent it, because they have physical access.  You're hosed.  Stop spamming.</htmltext>
<tokenext>Just stop Spamming , and they 'll stop rooting you .
And do n't ask us how to prevent it , because they have physical access .
You 're hosed .
Stop spamming .</tokentext>
<sentencetext>Just stop Spamming, and they'll stop rooting you.
And don't ask us how to prevent it, because they have physical access.
You're hosed.
Stop spamming.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561784</id>
	<title>Re:If they do this..</title>
	<author>richlv</author>
	<datestamp>1261907820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>isn't this "circumvention of protection measures" ?<nobr> <wbr></nobr>:)<br>if you don't plan to go to court, send them some nasty dmca letter (assuming you both are in usa).</p></htmltext>
<tokenext>is n't this " circumvention of protection measures " ?
: ) if you do n't plan to go to court , send them some nasty dmca letter ( assuming you both are in usa ) .</tokentext>
<sentencetext>isn't this "circumvention of protection measures" ?
:)if you don't plan to go to court, send them some nasty dmca letter (assuming you both are in usa).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557618</id>
	<title>colo or STFU</title>
	<author>Anonymous</author>
	<datestamp>1261859460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>The OP sounds like one of the thousands of self-important pricks I've spoken to in the 6 years I've spent in hosting. Nobody gives a shit about your server, or your projects. They're just doing their job, and faced with a "fuck you you're not getting my password" I've personally reset passwords to 50+ character passwords once I'm done.</p><p>Don't like it? Either build your own damn datacenter, or find a provider to sell you power, ping, and pipe on the 97 and manage a server you built yourself. If you own the machine, you can do whatever asinine, paranoid, double-secret encryption scheme you want.</p><p>Of course, if the machine is going down "mysteriously" and you need these "tech monkeys" to look at your logs, I highly doubt you're enough of an admin to handle coloing your own servers.</p></htmltext>
<tokenext>The OP sounds like one of the thousands of self-important pricks I 've spoken to in the 6 years I 've spent in hosting .
Nobody gives a shit about your server , or your projects .
They 're just doing their job , and faced with a " fuck you you 're not getting my password " I 've personally reset passwords to 50 + character passwords once I 'm done.Do n't like it ?
Either build your own damn datacenter , or find a provider to sell you power , ping , and pipe on the 97 and manage a server you built yourself .
If you own the machine , you can do whatever asinine , paranoid , double-secret encryption scheme you want.Of course , if the machine is going down " mysteriously " and you need these " tech monkeys " to look at your logs , I highly doubt you 're enough of an admin to handle coloing your own servers .</tokentext>
<sentencetext>The OP sounds like one of the thousands of self-important pricks I've spoken to in the 6 years I've spent in hosting.
Nobody gives a shit about your server, or your projects.
They're just doing their job, and faced with a "fuck you you're not getting my password" I've personally reset passwords to 50+ character passwords once I'm done.Don't like it?
Either build your own damn datacenter, or find a provider to sell you power, ping, and pipe on the 97 and manage a server you built yourself.
If you own the machine, you can do whatever asinine, paranoid, double-secret encryption scheme you want.Of course, if the machine is going down "mysteriously" and you need these "tech monkeys" to look at your logs, I highly doubt you're enough of an admin to handle coloing your own servers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560402</id>
	<title>Sounds like you</title>
	<author>Anonymous</author>
	<datestamp>1261844580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>shouldn't have made your root password the same as your password for email and/or banking. Too bad, looks like you'll have to learn a new password to use for everything!</p></htmltext>
<tokenext>should n't have made your root password the same as your password for email and/or banking .
Too bad , looks like you 'll have to learn a new password to use for everything !</tokentext>
<sentencetext>shouldn't have made your root password the same as your password for email and/or banking.
Too bad, looks like you'll have to learn a new password to use for everything!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888</id>
	<title>Stop being a douche</title>
	<author>jascat</author>
	<datestamp>1261852980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>As someone that works in support for a hosting provider, you're the type of customer that irritates me the most. While they shouldn't be rebooting your box to get root access without your consent, you should at least help them help you. Give them an account with limited sudo access to view your logs. If that won't do, then provide them with the necessary logs. If that's not good enough, don't expect support and move your stuff to some place that doesn't provide the level of support you're paying for.</htmltext>
<tokenext>As someone that works in support for a hosting provider , you 're the type of customer that irritates me the most .
While they should n't be rebooting your box to get root access without your consent , you should at least help them help you .
Give them an account with limited sudo access to view your logs .
If that wo n't do , then provide them with the necessary logs .
If that 's not good enough , do n't expect support and move your stuff to some place that does n't provide the level of support you 're paying for .</tokentext>
<sentencetext>As someone that works in support for a hosting provider, you're the type of customer that irritates me the most.
While they shouldn't be rebooting your box to get root access without your consent, you should at least help them help you.
Give them an account with limited sudo access to view your logs.
If that won't do, then provide them with the necessary logs.
If that's not good enough, don't expect support and move your stuff to some place that doesn't provide the level of support you're paying for.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560960</id>
	<title>price??</title>
	<author>upyourserver</author>
	<datestamp>1261852800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How much are you paying for this server you are talking about???</htmltext>
<tokenext>How much are you paying for this server you are talking about ? ?
?</tokentext>
<sentencetext>How much are you paying for this server you are talking about??
?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556950</id>
	<title>rooted? What does this word mean?</title>
	<author>bogaboga</author>
	<datestamp>1261853580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"...They asked me for the root password, which I flatly denied (as I always do), and then they rooted the server anyway, bringing it down and poking around through my logs.."</p><p>What does the word "rooted" mean in this case? They did not have the root password so what is the posted referring to here?</p><p>Disclaimer: I am no computer geek.</p></htmltext>
<tokenext>" ...They asked me for the root password , which I flatly denied ( as I always do ) , and then they rooted the server anyway , bringing it down and poking around through my logs.. " What does the word " rooted " mean in this case ?
They did not have the root password so what is the posted referring to here ? Disclaimer : I am no computer geek .</tokentext>
<sentencetext>"...They asked me for the root password, which I flatly denied (as I always do), and then they rooted the server anyway, bringing it down and poking around through my logs.."What does the word "rooted" mean in this case?
They did not have the root password so what is the posted referring to here?Disclaimer: I am no computer geek.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559114</id>
	<title>Have to disagree a bit....</title>
	<author>klubar</author>
	<datestamp>1261827960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Don't know exactly what you're using your server for, but we host various clients with a top-tier hosting provider.  One of the things I really like about this provider is that they will proactively help us with problems on our server. Part of what we pay them for is to alert us to problems and their indepth knowledge of the OS and sortware.  They deal with the server OS and software (apache, mysql, etc.) everyday and have certified experts on staff.  I consider it an advantage to host with a provider that can provide good advice and expert knowledge.  I really doubt that they have a great (or any) interest in looking at our data or seeing who is browsing our sites.</p><p>Perhaps you are being a bit paranoid -- or over estimating the interest of your provider in whatever you do.  Out of the couple of bucks you pay your hosting provider each month they don't have enough money to dig into your software.</p><p>If you really can't trust anyone to host your site, go with raw rack space and provide your own server.</p><p>It's not that hard of a problem to solve.</p></htmltext>
<tokenext>Do n't know exactly what you 're using your server for , but we host various clients with a top-tier hosting provider .
One of the things I really like about this provider is that they will proactively help us with problems on our server .
Part of what we pay them for is to alert us to problems and their indepth knowledge of the OS and sortware .
They deal with the server OS and software ( apache , mysql , etc .
) everyday and have certified experts on staff .
I consider it an advantage to host with a provider that can provide good advice and expert knowledge .
I really doubt that they have a great ( or any ) interest in looking at our data or seeing who is browsing our sites.Perhaps you are being a bit paranoid -- or over estimating the interest of your provider in whatever you do .
Out of the couple of bucks you pay your hosting provider each month they do n't have enough money to dig into your software.If you really ca n't trust anyone to host your site , go with raw rack space and provide your own server.It 's not that hard of a problem to solve .</tokentext>
<sentencetext>Don't know exactly what you're using your server for, but we host various clients with a top-tier hosting provider.
One of the things I really like about this provider is that they will proactively help us with problems on our server.
Part of what we pay them for is to alert us to problems and their indepth knowledge of the OS and sortware.
They deal with the server OS and software (apache, mysql, etc.
) everyday and have certified experts on staff.
I consider it an advantage to host with a provider that can provide good advice and expert knowledge.
I really doubt that they have a great (or any) interest in looking at our data or seeing who is browsing our sites.Perhaps you are being a bit paranoid -- or over estimating the interest of your provider in whatever you do.
Out of the couple of bucks you pay your hosting provider each month they don't have enough money to dig into your software.If you really can't trust anyone to host your site, go with raw rack space and provide your own server.It's not that hard of a problem to solve.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557558</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559536</id>
	<title>Re:You're complicating things.</title>
	<author>Anonymous</author>
	<datestamp>1261832160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sounds like it's too late this time around (pay the $35 and go from there), but to be proactive against next time, change the name of your root account, then create a limited access user named "root" that they can use to check logs, etc.  Have all activity of this account log off-site.  Sounds to me like either a: they want to be able to go cowboy-troubleshooting and see the entire picture (and they might suspect you of violating a TOS or two and want to gather evidence prior to you touching the box), or b: someone goofed and wants to be able to log in as root to quickly fix the problem they don't want to admit to having caused.  Most likely the first, but possibly the second.</p><p>Always good policy to change the name of your root account anyway.</p></htmltext>
<tokenext>Sounds like it 's too late this time around ( pay the $ 35 and go from there ) , but to be proactive against next time , change the name of your root account , then create a limited access user named " root " that they can use to check logs , etc .
Have all activity of this account log off-site .
Sounds to me like either a : they want to be able to go cowboy-troubleshooting and see the entire picture ( and they might suspect you of violating a TOS or two and want to gather evidence prior to you touching the box ) , or b : someone goofed and wants to be able to log in as root to quickly fix the problem they do n't want to admit to having caused .
Most likely the first , but possibly the second.Always good policy to change the name of your root account anyway .</tokentext>
<sentencetext>Sounds like it's too late this time around (pay the $35 and go from there), but to be proactive against next time, change the name of your root account, then create a limited access user named "root" that they can use to check logs, etc.
Have all activity of this account log off-site.
Sounds to me like either a: they want to be able to go cowboy-troubleshooting and see the entire picture (and they might suspect you of violating a TOS or two and want to gather evidence prior to you touching the box), or b: someone goofed and wants to be able to log in as root to quickly fix the problem they don't want to admit to having caused.
Most likely the first, but possibly the second.Always good policy to change the name of your root account anyway.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562684</id>
	<title>Use a server designed for use in a data center</title>
	<author>Anonymous</author>
	<datestamp>1261923660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I cannot believe you have a server colocated in a 3rd party data center without true full remote access eg something like HPs integrated lights out management  - ILO. That would give you complete KVM, hardware reset/power on/off, hdd/floppy/usb/cdrom redirection, with all the encryption you need not to mention hardware logging/alert features so you know if someone has physically tampered with the server.</p><p>Well worth the modest ILO license fee, the only time anyone needs to touch the server is when some hardware is actually broken.</p><p>OS fault? No problem boot from a cdrom repair disk 1000 miles away.</p></htmltext>
<tokenext>I can not believe you have a server colocated in a 3rd party data center without true full remote access eg something like HPs integrated lights out management - ILO .
That would give you complete KVM , hardware reset/power on/off , hdd/floppy/usb/cdrom redirection , with all the encryption you need not to mention hardware logging/alert features so you know if someone has physically tampered with the server.Well worth the modest ILO license fee , the only time anyone needs to touch the server is when some hardware is actually broken.OS fault ?
No problem boot from a cdrom repair disk 1000 miles away .</tokentext>
<sentencetext>I cannot believe you have a server colocated in a 3rd party data center without true full remote access eg something like HPs integrated lights out management  - ILO.
That would give you complete KVM, hardware reset/power on/off, hdd/floppy/usb/cdrom redirection, with all the encryption you need not to mention hardware logging/alert features so you know if someone has physically tampered with the server.Well worth the modest ILO license fee, the only time anyone needs to touch the server is when some hardware is actually broken.OS fault?
No problem boot from a cdrom repair disk 1000 miles away.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558358</id>
	<title>possible way they do it</title>
	<author>arbiter1</author>
	<datestamp>1261822080000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Buddy of mine had a box at ovh and he found ssh keys stored in the "/root/.ssh" which can be setup to allow log in without need of the password, he found stored ssh keys in there from them and log's showing someone from the datacenter going in there and poking around. you should check in there to see if there are keys in there and delete them and change all your passwords.</htmltext>
<tokenext>Buddy of mine had a box at ovh and he found ssh keys stored in the " /root/.ssh " which can be setup to allow log in without need of the password , he found stored ssh keys in there from them and log 's showing someone from the datacenter going in there and poking around .
you should check in there to see if there are keys in there and delete them and change all your passwords .</tokentext>
<sentencetext>Buddy of mine had a box at ovh and he found ssh keys stored in the "/root/.ssh" which can be setup to allow log in without need of the password, he found stored ssh keys in there from them and log's showing someone from the datacenter going in there and poking around.
you should check in there to see if there are keys in there and delete them and change all your passwords.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557532</id>
	<title>Re:Stop being a douche</title>
	<author>hacker</author>
	<datestamp>1261858620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> <em>"Give them an account with limited sudo access to view your logs."</em></p></div> </blockquote><p>I can't do that, since they are now prohibiting me access to my server unless I hand over the root password. They're not asking for logs, they're asking for the password to the 'root' account.</p><blockquote><div><p> <em>"If that won't do, then provide them with the necessary logs. If that's not good enough, don't expect support and move your stuff to some place that doesn't provide the level of support you're paying for."</em></p></div> </blockquote><p>I pay several thousand dollars a year for their disgusting service, and am going to be migrating away ASAP. Again, they're not asking for logs, they're demanding root. Two very different things.

</p><p>Right now, they won't give me KVM access so I can log in remotely and fix the networking they broke, so I can get my server back online. It's been down 2 days now because of this.</p></div>
	</htmltext>
<tokenext>" Give them an account with limited sudo access to view your logs .
" I ca n't do that , since they are now prohibiting me access to my server unless I hand over the root password .
They 're not asking for logs , they 're asking for the password to the 'root ' account .
" If that wo n't do , then provide them with the necessary logs .
If that 's not good enough , do n't expect support and move your stuff to some place that does n't provide the level of support you 're paying for .
" I pay several thousand dollars a year for their disgusting service , and am going to be migrating away ASAP .
Again , they 're not asking for logs , they 're demanding root .
Two very different things .
Right now , they wo n't give me KVM access so I can log in remotely and fix the networking they broke , so I can get my server back online .
It 's been down 2 days now because of this .</tokentext>
<sentencetext> "Give them an account with limited sudo access to view your logs.
" I can't do that, since they are now prohibiting me access to my server unless I hand over the root password.
They're not asking for logs, they're asking for the password to the 'root' account.
"If that won't do, then provide them with the necessary logs.
If that's not good enough, don't expect support and move your stuff to some place that doesn't provide the level of support you're paying for.
" I pay several thousand dollars a year for their disgusting service, and am going to be migrating away ASAP.
Again, they're not asking for logs, they're demanding root.
Two very different things.
Right now, they won't give me KVM access so I can log in remotely and fix the networking they broke, so I can get my server back online.
It's been down 2 days now because of this.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558178</id>
	<title>Take your offsite backup and walk away?</title>
	<author>Monolith1</author>
	<datestamp>1261820340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If they dont have your root account, and they wont play nice, perhaps you could take your offsite backup and walk away?</htmltext>
<tokenext>If they dont have your root account , and they wont play nice , perhaps you could take your offsite backup and walk away ?</tokentext>
<sentencetext>If they dont have your root account, and they wont play nice, perhaps you could take your offsite backup and walk away?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30563414</id>
	<title>Just set up your own</title>
	<author>awpoopy</author>
	<datestamp>1261932480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I stopped using hosting providers 10 years ago. There's no f*cking way, I'll ever do that again. THERE IS NO SUBSTITUTE for physical access to your own machine.</htmltext>
<tokenext>I stopped using hosting providers 10 years ago .
There 's no f * cking way , I 'll ever do that again .
THERE IS NO SUBSTITUTE for physical access to your own machine .</tokentext>
<sentencetext>I stopped using hosting providers 10 years ago.
There's no f*cking way, I'll ever do that again.
THERE IS NO SUBSTITUTE for physical access to your own machine.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30573102</id>
	<title>Re:If they do this..</title>
	<author>Angus McNitt</author>
	<datestamp>1262025300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>From what I took away from the article, he was complaining about bandwidth and LOS to the server. A better analogy would be going to DOT to complain about a bridge and them asking for your car keys to test it. Then 'jacking it when you say no.
<br> <br>
Having been on both sides of this, like just about every other slashdoter, I take the whole situation with a bit of salt. I have seen colo-techs access machines they had no business in, but have also had calls from customers who claim that our network went down when we don't have anything on our logs. There is a right way to handle this that just about everyone has mentioned, (send them the logs or move to a different colo). However in the heat of the moment, who knows what happened.
<br> <br>
Regardless, if he feels that he has a large enough physical security problem to warrant the encryption to protect it from staff, leave! It sets a bad precedent on both sides and just sows seeds for future problems. He will always see them as invasive bastards, and they will see him as a righteous PITA. Better to just move on.</htmltext>
<tokenext>From what I took away from the article , he was complaining about bandwidth and LOS to the server .
A better analogy would be going to DOT to complain about a bridge and them asking for your car keys to test it .
Then 'jacking it when you say no .
Having been on both sides of this , like just about every other slashdoter , I take the whole situation with a bit of salt .
I have seen colo-techs access machines they had no business in , but have also had calls from customers who claim that our network went down when we do n't have anything on our logs .
There is a right way to handle this that just about everyone has mentioned , ( send them the logs or move to a different colo ) .
However in the heat of the moment , who knows what happened .
Regardless , if he feels that he has a large enough physical security problem to warrant the encryption to protect it from staff , leave !
It sets a bad precedent on both sides and just sows seeds for future problems .
He will always see them as invasive bastards , and they will see him as a righteous PITA .
Better to just move on .</tokentext>
<sentencetext>From what I took away from the article, he was complaining about bandwidth and LOS to the server.
A better analogy would be going to DOT to complain about a bridge and them asking for your car keys to test it.
Then 'jacking it when you say no.
Having been on both sides of this, like just about every other slashdoter, I take the whole situation with a bit of salt.
I have seen colo-techs access machines they had no business in, but have also had calls from customers who claim that our network went down when we don't have anything on our logs.
There is a right way to handle this that just about everyone has mentioned, (send them the logs or move to a different colo).
However in the heat of the moment, who knows what happened.
Regardless, if he feels that he has a large enough physical security problem to warrant the encryption to protect it from staff, leave!
It sets a bad precedent on both sides and just sows seeds for future problems.
He will always see them as invasive bastards, and they will see him as a righteous PITA.
Better to just move on.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559922</id>
	<title>hosting providers</title>
	<author>Anonymous</author>
	<datestamp>1261837080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>if you are having those issues its time to move on. Most likely you are on a large broadcast domain with hundreds of machines at worst and 50- 60 at best. most likely some fool is broadcasting your ip space and taking you down.</p><p>move on to someone else. I was a neteng who inherited a network like that and bought my time to get out. it was an unmitigated disaster.</p></htmltext>
<tokenext>if you are having those issues its time to move on .
Most likely you are on a large broadcast domain with hundreds of machines at worst and 50- 60 at best .
most likely some fool is broadcasting your ip space and taking you down.move on to someone else .
I was a neteng who inherited a network like that and bought my time to get out .
it was an unmitigated disaster .</tokentext>
<sentencetext>if you are having those issues its time to move on.
Most likely you are on a large broadcast domain with hundreds of machines at worst and 50- 60 at best.
most likely some fool is broadcasting your ip space and taking you down.move on to someone else.
I was a neteng who inherited a network like that and bought my time to get out.
it was an unmitigated disaster.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558532</id>
	<title>Do your job.</title>
	<author>meburke</author>
	<datestamp>1261823460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Did you buy managed service? Let them manage your system or else find out what's causing the problem yourself and report it. If you think you are better able to manage the system than they are, examine the logs yourself when the system is up and figure out what happened. You may have to boost your logging level and install/enable some admin tools, but if they think they can determine the problem by looking at the logs, you should be able to do it also.</p></htmltext>
<tokenext>Did you buy managed service ?
Let them manage your system or else find out what 's causing the problem yourself and report it .
If you think you are better able to manage the system than they are , examine the logs yourself when the system is up and figure out what happened .
You may have to boost your logging level and install/enable some admin tools , but if they think they can determine the problem by looking at the logs , you should be able to do it also .</tokentext>
<sentencetext>Did you buy managed service?
Let them manage your system or else find out what's causing the problem yourself and report it.
If you think you are better able to manage the system than they are, examine the logs yourself when the system is up and figure out what happened.
You may have to boost your logging level and install/enable some admin tools, but if they think they can determine the problem by looking at the logs, you should be able to do it also.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559764</id>
	<title>There is a very good reason they're doing this</title>
	<author>maas15</author>
	<datestamp>1261835040000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>I know exactly why your hosting provider needs your root password - that's because it's absolutely impossible to tell whats wrong with your server without a valid login, preferably root. If your machines aren't showing orange hardware failure lights, and you have no proof or data on a networking outage, then it's 90\% sure to be an issue with the software on your machine. Since it's the most likely problem, it's unreasonable to expect your hosting provider to immediately spend a lot of time investigating the last 10\%.

You have two options (three actually):
1) Provide a root login
2) fix it yourself (this may require going to the datacenter in person)
3) see if they can work with an account with limited priviledges (it must be able to read logs and see all processes at the least). You also might want to try posting on serverfault - I can't comment on the technical end as you've supplied no detail

Actually the support staff would probably be happiest if you fixed it yourself. In addition, have you considered that they may have brought down your machine or machines, to run memtest86+ or the like? Are you *sure* they rooted it?



My only advice is to see if they'll accept a limited account (that can go through logs and see all the running processes).</htmltext>
<tokenext>I know exactly why your hosting provider needs your root password - that 's because it 's absolutely impossible to tell whats wrong with your server without a valid login , preferably root .
If your machines are n't showing orange hardware failure lights , and you have no proof or data on a networking outage , then it 's 90 \ % sure to be an issue with the software on your machine .
Since it 's the most likely problem , it 's unreasonable to expect your hosting provider to immediately spend a lot of time investigating the last 10 \ % .
You have two options ( three actually ) : 1 ) Provide a root login 2 ) fix it yourself ( this may require going to the datacenter in person ) 3 ) see if they can work with an account with limited priviledges ( it must be able to read logs and see all processes at the least ) .
You also might want to try posting on serverfault - I ca n't comment on the technical end as you 've supplied no detail Actually the support staff would probably be happiest if you fixed it yourself .
In addition , have you considered that they may have brought down your machine or machines , to run memtest86 + or the like ?
Are you * sure * they rooted it ?
My only advice is to see if they 'll accept a limited account ( that can go through logs and see all the running processes ) .</tokentext>
<sentencetext>I know exactly why your hosting provider needs your root password - that's because it's absolutely impossible to tell whats wrong with your server without a valid login, preferably root.
If your machines aren't showing orange hardware failure lights, and you have no proof or data on a networking outage, then it's 90\% sure to be an issue with the software on your machine.
Since it's the most likely problem, it's unreasonable to expect your hosting provider to immediately spend a lot of time investigating the last 10\%.
You have two options (three actually):
1) Provide a root login
2) fix it yourself (this may require going to the datacenter in person)
3) see if they can work with an account with limited priviledges (it must be able to read logs and see all processes at the least).
You also might want to try posting on serverfault - I can't comment on the technical end as you've supplied no detail

Actually the support staff would probably be happiest if you fixed it yourself.
In addition, have you considered that they may have brought down your machine or machines, to run memtest86+ or the like?
Are you *sure* they rooted it?
My only advice is to see if they'll accept a limited account (that can go through logs and see all the running processes).</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558928
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559006
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557944
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561518
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558234
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557138
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557344
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558222
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560450
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30568096
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557960
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556962
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558914
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560822
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559536
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559466
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557532
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30586712
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30565480
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561784
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557636
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30588030
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558850
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556876
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556794
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559634
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559246
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559012
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561046
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558424
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556950
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557306
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557494
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557896
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556950
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557028
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557558
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559114
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30569330
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557634
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559182
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562036
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560070
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557876
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562404
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560454
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559102
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30573102
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557828
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30566094
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557890
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557624
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557302
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30567796
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30586644
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559090
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559128
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_26_1520255_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559440
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556894
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557506
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558850
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30569330
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557960
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559536
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560822
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559466
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557828
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559090
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556750
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556880
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560070
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558892
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559246
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557160
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557944
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557494
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557306
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562448
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557634
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560454
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30573102
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557624
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30566094
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30567796
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557636
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30588030
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558928
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556830
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558424
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561046
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561784
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556876
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556794
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556824
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557558
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559114
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556890
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556960
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556888
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557876
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557532
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30586712
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557302
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557060
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557618
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557080
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557006
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557890
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30586644
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558222
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559440
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556908
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558532
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557388
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559634
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557582
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559128
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559182
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562404
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559102
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30565480
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559006
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557896
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557864
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557032
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556936
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556954
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30560450
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30568096
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30562036
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30559012
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30561518
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556962
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558914
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558802
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556950
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557028
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557168
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30558920
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557018
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30556952
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557520
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_26_1520255.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557138
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_26_1520255.30557344
</commentlist>
</conversation>
