Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by matman

  1. Yeah, it'll depend on how "fresh" the originating mail server's DNS service and cache are. You'll find that after one day you start getting some e-mails, but it may take up to a week for some networks to find your new home. If your old host has shut down your domain and mail accounts, some mail servers will keep trying several times to reach you, so some of the mail you thought you "missed" might show up days later.
  2. To check the computers settings, at a command prompt, type ipconfig /all The last entry should be "DNS Servers." Normally a DHCP server will set these, so if they're getting their IPs from the same DHCP server then the DNS servers should also be the same. But apparently these are not. Really, the traceroutes themselves make no difference -- the failure to resolve happens between the requesting computer and the DNS server before the traceroute even begins. Notice how the bad one starts like this: Tracing route to depcopump.com [] And the good one starts like this: Tracing route to depcopump.com [] The one that's not resolving is plain and simple getting a bad answer from its DNS server. What OS are these machines? If they turn out to have the same DNS server(s), let us know what those are and the OS of the problem machines, and maybe I can help out some more.
  3. Yes, anytime you configure a computerized functionality for anything, you should test it, test it, test it, test it first. Then test it again before deploying for real!
  4. Yes the mail function should work fine -- I use it extensively on my sites here at TCH. Here is how it works: http://www.php.net/manual/en/ref.mail.php If you want to paste in here the actual script(s) that are not working for you, I'd be happy to have a look.
  5. I'm not sure I understand all of this. Say I have a domain (like matman.com) that is hosted here at TCH. Suppose main area of the website at www. matman.com is just a personal website, pictures of the kids, a blog, etc. If I am working with some people on an open-source project or some such thing, are you saying I would not be allowed to have a project.matman.com subdomain with info about the project, etc.? Or is it just that I couldn't give someone else access to keep that site updated? Or what exactly is the line being drawn here? I guess I thought that as long as there was only one DOMAIN I was OK (i.e. there was not a project.com site that redirects to project.matman.com). I guess I figured that the space and bandwidth limits should pretty much prevent one account from hogging a server. Just trying to get clear on what I/we can and can't do.
  6. If you have FrontPage extensions enabled, creating a folder automatically creates a bunch of subfolders as well. Then if you try to delete the folder via FTP you can't because it is not "empty" -- it contains all of those subfolders.
  7. Also, keep in mind that the asterisks literally only protect you from someone looking over your shoulder -- the contents are still passed to the server exactly the same way any normal text field would be.
  8. Weird. Maybe they are using your javascript as an active desktop background or screensaver or something? Doubtful, I admit And you say that adding that IP to IP Deny on CPanel didn't do the trick? I would suggest submitting a helpdesk ticket and getting a guru to try it for you, because if you have IP deny on that IP you should NOT be getting any new logfile entries originating from that IP.
  9. Can you copy-and-paste a few lines from your raw access logs so we can look at exactly what's happening?
  10. Yes, if all the requests are coming from just the one IP, then denying that IP would be more effective than hotlink protection in this case. It would also keep your stats from being effected. As for an attack, I'm not sure if that's the right thing to call it (although I guess I did earlier). But if there are requests coming with such frequency all from one IP, it would definitely NOT be the result of a website that references the images/script/whatever, since such a reference would result in lots of requests from lots of different IPs with the offending site as the referrer.
  11. I don't blame him, and in fact I'm very grateful for his caution. This is shared hosting after all, and not a good place for anyone running loose with too much access and not enough knowledge. You certainly seem to have the requisite knowledge, but I am glad that Bill grilled you good to make quadruple sure. That being said, congratulations on your "parole."
  12. Thanks also for making the two "rocks" smilies a lot smaller -- they were really cramping the text-entry area!
  13. If all the requests are coming from just one IP address, then it is quite weird indeed! Conventional bandwidth-stealing hotlinks are IMG tags whose SRC is on your domain instead of the domain of the page that contains the link. If that is what's going on, you should see lots of hits to the image(s) from lot of different IP addresses belonging to the visitors to the thief's site. It sounds like you're saying that in this case one IP is hitting these images over and over and over again. Why would anyone do that? Just to be a jerk? Almost like a low-intensity DOS attack?
  14. Good call! I was kind of wondering about that!
  15. Wouldn't hurt for an admin to blank out the DB password in musicfrisk's posting -- I know we're all family and all, but some things are still private, y'know! Oh, and musicfrisk, your posting made me blink a bunch of times at first. I'd really gotten out of the habit of using the "printf" command since I started writing so much ASP code at work -- it really is a better way than just using echo in many cases. I'll have to keep that in mind. Thanks! It is nice to have a place to look at other people's PHP code!
  16. Dig out the "welcome" e-mail you got when you had penguinbooks.com set up at TCH and try loggin in with the username and password in there. I'm pretty sure you'll find you'll end up where you needed to be. You can put your domain name, the IP address, the name of another site on the same server, or the "real" server name (in my case server21.totalchoicehosting.com) in your FTP client as "host" and it makes no difference. The name just gets translated into the IP address anyway. Think of a domain name as being like your name. If I want to call you, I can look up your name in the phone book and find your number, then call you. Or if I already know your phone # I can just call -- don't even really need to know your name. Once you're connected to the server by FTP, the server asks you to login. It knows that a particular login name is for a particular website, and that's how it knows which website root to direct you to. Sort of like that phone call -- I can get connected to your house with just the number, but then I have to ask to speak to you. If I don't ask for the right name, I could end up talking with your dad, mom, wife, kid, whoever. Awesome DNS explanations: DNS glossary
  17. Keep in mind that the FTP root you end up in depends on what username you log in with, not which hostname you point your FTP client toward.
  18. 5c is hexadecimal for "92" 92 is the ASCII code for the "\" character It looks like you must have a bunch of links on your homepage that have a "\" as the first character in the HREF. A quick search of the source code for your homepage shows bunches of them.
  19. Holy index! Hmmm, I saw the site from home yesterday, but now at work I see just the directory listing. Did something change or is there more here than meets the eye?
  20. Looks good to me. Perhaps the folks seeing the "TCH Network Operations Center" stuff have some faulty caching going on at their ISP that is causing them to see a message that USED to be there but isn't anymore.
  21. I'd say that TCH support in general rocks. With other web hosts, I'd find myself wondering if there was anybody really working there at all! No communication going on, you know? Here it is easy to see and know what is going on. ROCK!
  22. If you mean the "_vti_cnf" folders and so on, you should probably make sure you turn FrontPage support off before deleting them (I you decide to do so at all). Otherwise they may either not allow you to delete themselves, or they'll just re-create themselves automatically. The FrontPage extensions "auto-magically" (it's black magic, as far as I'm concerned!) create these folders and make notes for their own use about all of your files. Personally, I always try to get rid of the buggers. If you have a lot of files and folders they do eventually eat up a not-insignificant amount of space, and just generally make navigation a pain. But Mr. Weilbacher has a point as well about leaving well enough alone.
  23. Here's my general suggestion for all domain propagation issues: use a "hosts" file entry to work around it. The hosts file is the old-fashioned method of handling name-to-IP resolution back before there was DNS, and is still used sometimes to allow you to override DNS (which is what I am suggesting you do). The hosts file is simply a filed named "hosts" (no file extension. In windows NT or 2000 you'll find it in the windows\system 32\drivers\etc folder, but it might be easier just to use the find function to find it on your c: drive. Then open it with notepad. The file probably has a bunch of instructions in it; all those lines will be marked as "comments" (with a "#" sign) so that the operating system ignores them. At the end you'll see usually just one real entry, for "localhost." Add your entry on a new line after that. For my domain, it would be www.c-stone.net After adding your entry, save the file. Now when you type in your domain name, you should get your site, and any links will still take you to your site. Once you're sure your domain propagation is done, you can remove the entry you made in the hosts file (or do what I do and just put a "#" in front of it; this way you can later re-enable it easily by deleting the "#"). Be aware that doing this will enable you to see your site as if everything was working great, but it only works for you! Other people will still not be able to find your site until their DNS server have the new address/SOA.
  24. Newly-created subdomains should not take any time to "filter through" the internet. The reason this "filtering" process takes place is that local DNS servers cache information about who is the Start of Authority (SOA) for a given fully-qualified domain name (FWDN) and about what the IP is for the FQDN. When a local DNS server looks up an FQDN, it caches ("remembers") the answer about what the SOA and IP are. If another query is issued about that same FQDN within a certain timeframe (the "Time To Live or "TTL"), usually anywhere from 3 hours to 3 days, it won't go back and look it up again but will instead just serve up the answer it remembers from last time. Since it is not possible for a local DNS server to have any cached data for a newly-created subdomain (it should never have looked it up before, since it didn't exist), then when asked to look it up it should go to the SOA (which in this case would be the TCH nameservers) to find out the IP address. If the subdomain has already been created and added to TCH's DNS, it should show up right away. Now if you happened to check it before TCH's DNS got updated, your local DNS server might cache the "no such record" result and you won't see it right away. If you have a wildcard subdomain (such that anything.****** gets sent to www.******), it will cache that fact and re-direct you to your main page; it will then continue to do so until the TTL is expired.
  25. Not exactly true. PHP scripts can indeed be run from the command line or by a cron job. I'm not sure if the TCH servers are set up to allow this or not -- not sure if our cron jobs can access /usr/bin/php or not. Without shell access to experiment with the results I'd be rather wary to experiment with this. From the PHP manual: http://www.php.net/manual/en/features.commandline.php
  • Create New...