pyng
03-29-2001, 04:05 PM
Background: I have a dedicated server with serverhost.com, and my server is located within AOtech.net's facility in columbus, ohio. You may also find aotech to be related to zooga.net, ssmdata.net, server99.com, rackcolo.com, johnmacleod.com and perhaps also to simply1st.net, ohio1st.net. Why? Because these are apparently one of the few domains who have ip -> hostname points in aotech's /19 netblock. (see below)
Some of this information was present in other posts I've made, but I've pulled them together for completeness in a single post.
Problems faced:
1. Reboots.
I have had 3 occasions to ask for reboots so far. The first time was because I accidentally wrote an ipchains rule that firewalled me out of the system. I looked around for the right person to contact, found the serverhost emergency e-mail, sent off a request, and it got rebooted after a total of about one hour (including searching time). Not too good, but good enough since I don't ever plan to put any business-type things there.
The second time was on the same day as the first time. This time, I crashed it seeing how far I could push hdparm to get maximum speed out of my drive. Mailed serverhost emergency contact immediately... The next day - over 14 hours later, I managed to catch Jeffrey as he came on icq. He said my box had already been rebooted twice the day before. I said that my box still wasn't up and asked for the reboot again, but aotech were apparently not responding to his calls, and he had to wait for someone to get back to him. Eventually, over 16 hours from the start, someone called him back, and my box got rebooted. On logging in, I saw from the logs that the server had not been rebooted twice the day before - only the one time I'd requested.
The third time (now), my box simply stopped responding while I was typing something. I checked to make sure that it was just my box and not some network problem, and fired off another reboot request glumly. I also noted that my box was not totally FUBAR'ed. It still accepted connections on port 22,25,80, and my original ssh session had not terminated, just froze. Telnetting to the above open ports yielded a connection, but did not produce the usual banners (eg. SSH-1.99, 220 ESMTP etc.), so I decided to just leave my current connection in place, and also telnetted to the open ports, and left the connection open. Jeffrey said he had forwarded my reboot request to them, but knowing how long it took to get a reboot the last time, I went to sleep.
Woke up, still no reboot. When Jeffrey came on icq, I asked him what was happening with it, and he said that they had rebooted it at least twice already. Aotech must be lying their pants off - my connections to my server were still open since the night before, and any reboot would have caused the tcp connections to be broken. Jeffrey has no reason to lie about this to me - it just takes him a simple call/e-mail to ask for the reboot, so the act of replying to me takes as much effort as sending in the reboot request. Therefore, aotech is (@^#)(*&@. As of this writing (22 hours after sending my reboot request), it still has not been rebooted.
2. Reverse DNS
If that was not enough to scare you aware from them, try the slow response times for delegating reverse dns authority for my IPs to me. This is something that takes just a couple of minutes, but 2 weeks after being first connected, it's still not forthcoming.
3. "server99" login that ssh's to other machines
On top of all that, how about dodgy technicians? When my server was first setup by them, they had a "server99" login created on my machine. Perhaps they use it to monitor things if need be. If so, fine. But I found this in ~server99/.bash_history: "ssh -l keeb lo.st"
lo.st appears to be on a network close to, or perhaps part of, aotech. Whatever it is, a technician should not be using a customer's machine to ssh to other machines.
---
I hope this is sufficient to dissuade you from ever going with aotech again :)
Jeff's just said that he's planning to move me to his other facility because of the response times at aotech. phew.
[Edited by pyng on 03-29-2001 at 03:17 PM]
Some of this information was present in other posts I've made, but I've pulled them together for completeness in a single post.
Problems faced:
1. Reboots.
I have had 3 occasions to ask for reboots so far. The first time was because I accidentally wrote an ipchains rule that firewalled me out of the system. I looked around for the right person to contact, found the serverhost emergency e-mail, sent off a request, and it got rebooted after a total of about one hour (including searching time). Not too good, but good enough since I don't ever plan to put any business-type things there.
The second time was on the same day as the first time. This time, I crashed it seeing how far I could push hdparm to get maximum speed out of my drive. Mailed serverhost emergency contact immediately... The next day - over 14 hours later, I managed to catch Jeffrey as he came on icq. He said my box had already been rebooted twice the day before. I said that my box still wasn't up and asked for the reboot again, but aotech were apparently not responding to his calls, and he had to wait for someone to get back to him. Eventually, over 16 hours from the start, someone called him back, and my box got rebooted. On logging in, I saw from the logs that the server had not been rebooted twice the day before - only the one time I'd requested.
The third time (now), my box simply stopped responding while I was typing something. I checked to make sure that it was just my box and not some network problem, and fired off another reboot request glumly. I also noted that my box was not totally FUBAR'ed. It still accepted connections on port 22,25,80, and my original ssh session had not terminated, just froze. Telnetting to the above open ports yielded a connection, but did not produce the usual banners (eg. SSH-1.99, 220 ESMTP etc.), so I decided to just leave my current connection in place, and also telnetted to the open ports, and left the connection open. Jeffrey said he had forwarded my reboot request to them, but knowing how long it took to get a reboot the last time, I went to sleep.
Woke up, still no reboot. When Jeffrey came on icq, I asked him what was happening with it, and he said that they had rebooted it at least twice already. Aotech must be lying their pants off - my connections to my server were still open since the night before, and any reboot would have caused the tcp connections to be broken. Jeffrey has no reason to lie about this to me - it just takes him a simple call/e-mail to ask for the reboot, so the act of replying to me takes as much effort as sending in the reboot request. Therefore, aotech is (@^#)(*&@. As of this writing (22 hours after sending my reboot request), it still has not been rebooted.
2. Reverse DNS
If that was not enough to scare you aware from them, try the slow response times for delegating reverse dns authority for my IPs to me. This is something that takes just a couple of minutes, but 2 weeks after being first connected, it's still not forthcoming.
3. "server99" login that ssh's to other machines
On top of all that, how about dodgy technicians? When my server was first setup by them, they had a "server99" login created on my machine. Perhaps they use it to monitor things if need be. If so, fine. But I found this in ~server99/.bash_history: "ssh -l keeb lo.st"
lo.st appears to be on a network close to, or perhaps part of, aotech. Whatever it is, a technician should not be using a customer's machine to ssh to other machines.
---
I hope this is sufficient to dissuade you from ever going with aotech again :)
Jeff's just said that he's planning to move me to his other facility because of the response times at aotech. phew.
[Edited by pyng on 03-29-2001 at 03:17 PM]