Piotr GRD

The servers are available under many IPs. Especially the "Stevie" one. If you want the IP under which is available your website on this server then Krydos gave you the answer. Eventually you can also just check the DNS entries for your domain names hosted in here. If you need this for online payments then I believe you want either the IP of your website (to find it out read above) OR IP from which the outgoing connections go through and in a case of the server "Stevie" it's 65.19.143.2 and in a case of the server "Johnny" it's 64.62.211.131 - at least these are my results when I have just tried the outgoing connections with using cURL from the accounts on these servers. I don't know anything about online payments and procedures and techniques used, so unfortunatelly I can not give you the answer if you need either one or the other IP.

I'm sorry, but I can not find the username "karman" on the server "Stevie" (I don't have an admin access, though), and DNS records points domain name "templegothic.heliohost.org" to the IP of server "Johnny", so it looks like your account is on "Johnny", which is indeed unavailable for over 9 days already. More about situation of the server "Johnny" you can read in these topics: http://www.helionet.org/index/topic/13575-more-johnny-issues/ http://www.helionet.org/index/topic/13628-johnny-news/

I have started to write before your post, while I was checking DNS records and writing - your post has appear, so I have modified my words little bit for being somewhat complementation of yours. I think it does have a sense if you'll read at the beginning your "the simplest way is..." and then my "you can but you don't have to ...". Either way I think that main problem of epicmind is that he didn't told heliohost server anything about his domain name (didn't add it either as parked or add-on).

Did you add your domain name as the "parked" OR "add-on" in the cPanel on the HelioHost? If you'll add it as the "parked" it will point to the same folder where some other domain name already point to (ie. "epicmind.heliohost.org"). If you'll add it as the "add-on" domain it will point to the other folder (chosen by you). Your DNS records are OK and will work. But only when HelioHost server will be prepared to accept requests for your domain name and this will happen when you'll do above. You can you but you don't need to use HelioHost nameservers. It doesn't matter which nameservers you use if the DNS records on it are correct. And... this will not be "forwarding", no any redirection will happen, your domain will just point to the same files as your heliohost subdomain. I guess you have exactly this in mind while using "forward" word. As an addition to Krydos' explanation why you can't see your website while sending request just for the IP address without the host name - you can read about name based virtual hosts: http://en.wikipedia....ting#Name-based

If you really had 60 concurrent connections to the server then for the start maybe try to limit number of simultaneous connections in your FTP client. This may be (or may not be) the case that indeed you had so many connections while transferring your files.

I've just modified my previous post, it looks like it's a routing problem, access to this specific IP is blocked (at least from my side) much before the server itself. If I compare trace routes to two Stevie's IP, access to 216.218.192.170 stops when it should reach he.net (Hurricane Ellectric) network, so for me it looks like access to this IP has been simply blocked by this provider. (I may be wrong, of course.)

As far as I can see, at the moment there is a problem with the IP 216.218.192.170 being inaccessible at all (even for a ping). The server Stevie by itself seems to work fine, the other IPs, ie. 65.19.143.2, 65.19.143.3, 65.19.141.68 (Stevie has a lot of IPs pointed to it) are accessible and websites that are available on these IPs works fine. If you'll do a traceroute to these IPs you'll most probably notice that this is a routing problem much before reaching the Stevie server. As for the DNS issue... I can see such an issue for ie. Krydos' subdomain (different A records on ns1 and ns2), but not for mine or Byron's or for Ice IT Support's domain and few other that I have checked. @ potatoboy2 You are right, if my monitor shows no information about server load that's mean it can not access my testing account on this server to get the informations about this server load.

@ Ermu At the moment there seems to be no any DNS record for the tbf.heliohost.org domain name at ns1.heliohost.org nameserver. There is a valid DNS record on ns2.heliohost.org, though. Ns2 works intermittently, so when you (or anyone) will try to reach your website when ns2 works fine - you (or anyone) should get your website, when ns2 doesn't work, ns1 has no information about your subdomain, so your website would be unreachable. This is problem number one which you can check by yourself with using any "DIG" utility, ie. the one provided by me: http://heliohost.grd...pl/dns-checker/ Heliohost nameservers are known to be "out of sync" from time to time and that's why are scheduled for being synchronised every 24 hours (if nothing has been change), so you may check again tomorrow if this issue will resolve itself or not. If not then you may aware admins about it. Second problem with your tbf.heliohost.org subdomain is the "account queued" problem, as indeed Johnny does return deafult webpage when being asked for this address. This is most likely completely separate issue from the above DNS one and may have different reason, which I am not able to define for you, though.

Technically the server works. Static content is served with no any significant problems for most of the time. However dynamic content generated with using PHP processes (even very small and simple PHP scripts) is either served very slowly or ends up with "503" at the moment. My monitor can not even get the "server load" from it for most of the time for last ~4 hours (so it shows white "no info"). Just to confirm above two reports.

What is this "red incorrect" report about? If your domain registrar do check the existence of the DNS records on heliohost nameservers before let you change the domain delegation and it's the warning about ns1.heliohost.org having no information about your domain name, then it's correct warning, as indeed ns1.heliohost.org do not have any informations about your domain name at the moment. This is enough often the case that these nameservers are not synchronised instantly. You may ignore this warning and change the domain delegation into ns1/ns2.heliohost.org, anyway. Once every 24 hours heliohost nameservers are scheduled to synchronise all DNS entries, so ns1 should contain the entries for your domain name within these 24 hours period of time. You can check this with using any "DIG" utility, ie. the one provided by me for heliohost nameservers only: http://heliohost.grd...pl/dns-checker/

You could try to set it in the .htaccess file: php_value error_reporting 22519 though when I try to test it on Stevie I got error 500, so that would mean that it's impossible to change it through .htaccess. Other way - which works fine for me in my test on Stevie - is changing the error_reporting value directly in the PHP script: ini_set("error_reporting", E_ALL & ~E_NOTICE & ~E_DEPRECATED); I don't know where exactly in PHP-Nuke files you would have to put this, but I can imagine that in the configuration file - which is most likely included every time - would be most easy. However I can see on my Stevie's account that default error_reporting setting is now exactly 22519 so deprecation alerts should be ignored. If not, then most likely PHP-Nuke itself inside of its code is changing this value.

Error 500 very often mean that there is syntax error in the .htaccess file. First thing I recommend you to check is the way you are saving this file. Use pure ascii only, do NOT save it using UTF-8 or Unicode etc., non-ascii characters such as in example BOM (byte order mark) may result with syntax error. After you'll resolve your issue with error 500, remember that when being on a virtual host you have to provide RewriteBase when using mod_rewrite.

I am not the admin, so I can not be sure, but I found the "sumitpro" username on the Stevie server, which seems to match to your forum "sumitprosoft" username, you might want to try it. However heliohost nameservers do not have any DNS entries for your astrodpverma.com domain name.

Status of Stevie is displayed incorrectly, indeed. There is a topic about it on the forums, but obviously if you (or anyone) are not a frequent visitor of these forums, you may not spot it and base only on (currently incorrect) information provided on the main page. For me it looks like your account does not exists. There are no DNS records for "moth3r.heliohost.org" domain name on HelioHost nameservers and I can not find "moth3r" username on the list of existing accounts (either on Stevie or on Johnny). As I can see that back in November you had an issue with the account being suspended (and then unsuspended by admins) it's possible that something similar happend again and after some period of time account has been automatically deleted. However as I am not the admin all I can do is speculate. More informations you can get from admins only.

That's the "news" from December 2011: http://www.helionet....or-maintenance/ Stevie works fine recently. So it may be that either only you have problem with accessing the server OR there something wrong only with your website. @ admins: There should be a date/time provided in these news on main page, without such information it may lead to confusion, as we can see at the moment: 12 hours from when, for example?

Think about it as about some kind of opinion poll. And as every one of these it has some margin of error. I do not know what this margin of error is for Alexa, but let's suppose it's 0.1%. At the moment google.com is visited - according to Alexa for 3 months period of time - by 49.43% of global internet users. So either if it's 49.33% or 49.53% - the margin of error doesn't mean much, google.com will still be number 1 in Alexa ranking. On the other hand grd.net.pl is visited - according to Alexa - by 0.00041% of global internet users, so in this case the margin of error will make a huge difference.

DOMAIN NAME: grd.net.pl registrant type: individual And the individual is me. ; ) Thank you for using. : ) Yes, I do monitor over 20 webhosts. I believe that Alexa is counting unique visitors and not how many times website is visited, otherwise many website owners would try to bump their websites by visiting it by themselves, this technique is useless, though. So there have to be more people in India that visits my websites. Of course only people with Alexa toolbar are counted and not that many people have it (I don't have it and I won't have it), so Alexa ranking is very approximate for domains out of the top 100 000 (global) and much close to true only for top 1 000 (global) in my opinion.

As far as I can see, uni.me is another service with free "domains" (subdomains, for real). On the HelioHost side everything seems to be set correctly, but you need to change settings at the uni.me side. Depends on the possibilities that you have in there you need to either set the bharbet.uni.me in there to use ns1.heliohost.org and ns2.heliohost.org as the nameservers for this (sub)domain OR while still using their (uni.me) nameservers point the bharbet.uni.me with an "A" record to the IP 64.62.211.131. But if you'll try to access this subdomain at the moment there is a note from uni.me service - in the title - that the domain has been terminated for abuse. So...

The time on both - Stevie and Johnny - are correct (except small issue with time in HTTP headers sent from Stevie being 24 seconds behind for some reason, while time served inside PHP scripts with date and time functions is correct). Default timezone set on both servers is "America/Los_Angeles" - which is PST in winter and PDT in summer. If you want to use different timezone you have to specify your own value either inside of your PHP scripts (in every one of them) with: putenv("TZ=xyz"); or with: date_default_timezone_set("xyz"); OR for all your scripts with using the following entry in .htaccess file: SetEnv TZ xyz where xyz will be selected timezone identifier. All timezones you can find in here: http://php.net/manual/en/timezones.php If I'm right then most probably best for you will be using "Asia/Tehran" timezone, as this is the place where GMT+03:30 (IRST) is used in winter, and GMT+04:30 (IRDT) in summer.

Do you mean XAMPP? Or is there something called XXAMP that I don't know about? (Google return only results with misspelled XAMPP.) I use it on my Windows computer. And there is no problem with "install" (yes, in quotes). I've just extracted the content from the zip archive and here you go, it's "installed". All most commonly used functions already work after clicking "xampp_start.exe", just make sure your firewall will let apache and mysql to work.

This is NEVER safe to include data from external source. But if someone need to get the data from external source and use it, then there is another way. Get the data with using cURL or fsockopen() functions for example and then use it. If it's HTML then simply echo the code, if it's PHP code then do the eval() on it. Either way - especially if someone wants to eval() some PHP code - It's highly recommended to do some data verification before, for being sure that there is expected, valid and safe data on that external server.

Just for your information, if you didn't spot it while registering: what you describe - intermittent problems - is unfortunatelly expected and considered as "normal" behaviour of the server Johnny. As per "sign up" page: http://www.heliohost.org/home/signup

Just as a reminder note: While Wizard did fix the "queued" problem, the original one mentioned at the beginning with HTTP access being very slow for last couple of days is still unfixed.

Hold on with looking for the reason of your problem until the general problem with accessing websites on Stevie won't be fixed. There is such problem for last couple of days. The mentioned by Ice IT Support part of the code as is do completely nothing, maybe except using a single milisecond (or much less) of work for CPU.

I don't know, but it happend from time to time. If my monitor shows "HTTP" as fine but do not report the server load, then most likely (but not always!) accounts are "queued" (for main pages and return 404 for subpages) or PHP scripts return error 500 (which happend sometimes, too). It'll be most probably fixed as soon as one of the admins will execute some kind of "fix script" or something like that that they have for such situation.