Piotr GRD

Main point is - in my opinion:

"Expire" header says it can be cached for one month and various browsers may or may not cache it. My browser "decide" to not cache it - most likely because this is a "*.php?..." kind of URL which usually is source of dynamic content. But some browsers may cache it, especially if there is additionally "Cache-Control: public" header.

Some people may figure it out, some people may not.

To these people that will read this topic we may say: "try to clear the cache".

For these people that won't realize possibility of pages being cached and won't read about it anywhere admins may try to change the HTTP headers sent by the "signup.php" script. (ie. this IPB forum is sending "Expire" header with the time in the past, but imagine that it doesn't - some people may not spot new topics created right away but much later).

Sometimes we may also have some proxies between server and visitor (ie. when using computer in university or in some company network instead of learning/working hard ; ) ) and in such case proper cache dispositions in HTTP headers may be the only way for being sure that the current content of the page will be displayed and not the expired one.

As for my monitor - my monitor while accessing registration pages do not use any cache and always tries to get the response directly from server. But with pages that display my results I don't send any cache dispositions, so it's fully up to browsers/proxies/whatever if content of my pages is cached or not and for how long. Check if the time diplayed on the right of the graph is not older than 2 minutes for being sure.

Sorry, Krydos, my apologies. I've missed your avatar, it's dark blue, too, like xaav's avatar and while reading the forums quickly I usually put only a "blinking of an eye" period of time of attention to the column with author and all the rest of time to read the content of post. No any excuse... only explanation of how my error happend.

.. / Ice / xaav / Ice / dark blue again / Ice / xaav... sorry

This bot would not have to move mouse and actually "click" anything, just follow the URLs, read the HTML and javascript source code, interpret it accordingly and send the proper form. A proper form is most probably dependent on these javascripts.

Because at the moment sign ups are actually closed (for ~2 hours for Stevie and ~1.5 hour for Johnny).

It was already closed at the time of my previous post.

I would say that your best chance is to create a script (bot) that will actually access cPanel through HTTP and log in into your cPanel account and "click" whatever is needed to be clicked inside of it for you. Because - as written already by xaav - no any other script executed by you will have enough privileges/permissions to actually create FTP account and cPanel don't have API to allow you to do this in more simple way.

This should not be that hard, though, for someone that already did code such bots. Only question is the one posted by Krydos - "is it worth it?". My only experience was coding a bot that log in into SMF forum, grab the page (or RSS feed) that is available only for logged in users and then log out. You (your bot) need to log in, access the "FTP Accounts", fill up the form and send it. There is one catch: I see that a lot in cPanel - including this form - depends on functionality of the javascript. So you need to be familiar with javascript, too (I am not), to make your bot aware of these javascripts used in there and this may be the most difficult point (at least this would be most difficult for me).

...but I have no idea why people keep having problems signing up at this point.

I have an idea. Cache. Check the HTTP headers.

www.heliohost.org/scripts/signup.php?plan=1

HTTP/1.1 200 OK
Date: Thu, 03 Nov 2011 16:37:41 GMT
...
Expires: Sat, 03 Dec 2011 16:37:41 GMT
...

www.heliohost.org/scripts/signup.php?plan=9

HTTP/1.1 200 OK
Date: Thu, 03 Nov 2011 16:38:29 GMT
...
Expires: Sat, 03 Dec 2011 16:38:29 GMT
...

To (future) users: clear your browser cache.

To HelioHost admins: change HTTP headers so these pages won't be cached by browsers.

The informations about when registrations are open or not are already displayed on my server monitor (link in my signature).

And indeed, yesterday and today registrations were not open at all.

At least my system did not detect it being open, and I'm checking once every 2 minutes.

As to the last error provided - problem was obvious:

"DNS Error: DNS server returned general failure"

As to the original issue with "454 454 TLS currently unavailable (state 9)" and a long delay in delivery - I found this:

http://www.google.com/support/forum/p/gmai...a748df20407a337

Brandon L, Google Employee, Gmail Engineer, 6/2/11

 

Yes, we changed our policy to now keep trying to use STARTTLS for 24 hours, then send an NDR to the sender, and then fall back to not using STARTTLS.

 

Before, you would have had an unknown 1 hour delay, now you have a larger delay and at least some way to know why you have the delay. I agree that the larger delay is annoying, but this is due to a mis-configuration of your server, and the point now is that you can more easily find out about the mis-configuration and hopefully fix it.

 

(...)

Changes

After reading repeated from time to time questions about when the registrations are open I decided to start to monitor if the registrations are open or closed.

Data are collected since 2011-10-21, Monday, and by browsing archive results for several days back one can see when is his/her best chance to register new account (not necessarily just after midnight).

---------------------

It starts to be a little mess... at least for my own eyes.

I have to sort the graphs in little different way to make it better for readability... : )

In last three days registrations were open:

- 2011-10-17, Monday - between 07:00 and 12:02 UTC (00:00 - 05:02 PDT)

- 2011-10-18, Tuesday - between 07:00 and 11:20 UTC (00:00 - 04:20 PDT)

- 2011-10-19, Wednesday - between 07:00 and 10:20 and then between 10:42 and 10:52 UTC (00:00 - 03:20 and 03:42 - 03:52 PDT)

These data will be available on my server monitor, soon.

Error 28 mean that no space left on device.

I see no problem with disk space on /var/lib/mysql partition, however at the moment there is only 4 MB space on /tmp, so it's possible that there was temporarily no disk space at all and if MySQL is using /tmp for some operations then that was the reason.

ns2.heliohost.org is intermittently unavailable, yes. You can check this on my server monitor, link in my signature. It's on the same server with "Johnny" which is unstable. But as long as at least one of the nameservers used by you for your domain name is available at any given time your domain will be available. If you're not comfortable with this, though, you may switch to use any other nameservers instead of or along with heliohost nameservers, and correctly set all DNS records on them to point your domain name to the heliohost server where your account is and all records for GApps, too.

I am not much familiar with these protocols (POP3, IMAP, SMTP), unfortunatelly, I've never put much attention to mail services on any webhost. So is this possible for me to add such monitoring?... In the future - maybe. In the near future - rather not, sorry.

Thank you for good words about the service. I'm glad it's useful. : )

What disk space usage/limit every single account has is not related to the (global) disk space usage in /home or /home1, either.

I do NOT know if this is in any way related or not, but for 24+ hours there is no free disk space on partition that contain /var on Stevie.

(...)

What I find weird about this (apart from the 30KB memory limit) is that it's a very contradictory message. 30720 (30KB) is significantly less than 134217728 (128MB), and so there shouldn't really be a problem...

(...)

Just to clear your confusion:

The error mean that the system failed to allocate another 30 kB of memory after (let's say) 127.99 MB being already allocated before processing line 17 of your script.

If you are coding by yourself you might want to use memory_get_usage(true); function to debug how much memory is allocated for your script. You could put it in various parts of your code to check memory consumption of these parts of your code. Then you can think about what you can code in different way to optimise memory consumption.

--------

I had a problem not so long time ago with one of my custom scripts (the biggest, most server resources consumming one) after moving between hosts. While on first webhost I had no problems, on the second one the script went into exhausting allowed limit of 128MB of memory. What was the difference between two webhosts? One is using 32bit system, second one has 64bit system. I don't know if this is the case for all 32/64bit systems, but on the one I used the same processes takes almost twice (not twice, but little less than twice) amount of memory on 64bit system than 32bit.

So I had to optimise my script. The amount of data that my script used when being stored in files was just ~2 MB, however when being loaded, exploded into arrays and processed accordingly it takes MUCH more. I have changed procedure to load into arrays only the part of data that is currently needed, not all data at once. Unset unused variables/arrays also helped a little bit. The size of the PHP script itself doesn't mean much; what and how the script is doing - does.

I think that in here:

http://www.helionet.org/index/index.php?showtopic=10527

you'll find the informations from administration about this problem.

@ thedogstudio

I've replied in here already:

http://www.helionet.org/index/index.php?showtopic=10552

On HelioHost side your *.cu.cc address is set correctly and works (if I bypass the DNS system).

However there seems to be problem on cu.cc side. None of cu.cc nameservers works, so no-one can access either cu.cc or any of the subdomains of it.

On HelioHost side your *.cu.cc address is set correctly and works (if I bypass the DNS system).

However there seems to be problem on cu.cc side. None of cu.cc nameservers works, so no-one can access either cu.cc or any of the subdomains of it.

The problem is there again. Today, at least since 10am (GMT) all sites on stevie I tryed are queued again.

Since ~09:16 UTC / GMT.

September 1st, ~08:38 UTC.

September 15th, ~08:36 UTC.

September 19th, ~08:44 UTC.

September 20th, ~09:16 UTC.

Not so much regular as before in July ( LINK ), but maybe it's worth to search again for the reason of this problem and solution? ( LINK )

As to MySQL thing...

No, jje. I think that UR710 is asking for the eventual MySQL resource limits per account such as max_questions, max_updates, max_connections which are per hour limits (if set at all, which is often the case on free webhosts - very understandable if webhost want to have stable server with having large enough number of users on this server, otherwise there is high risk of MySQL slows down or taking down the whole server completely).

http://dev.mysql.com/doc/refman/5.0/en/user-resources.html

DNS

Your settings are currently fine and if previously the TTL for the NS records on cz.cc side was the same then your domain should be available for the whole world within 2 hours. For me works already.

I am not an admin, but I think you should be fine with it.

Note that, though, that if you will change authoritative nameservers used for your domain at your domain registrar - the change may take even 24-48 hours until it takes effect on the whole world.

If you will not change the authoritative nameservers at all, but only the "A" records on these to point the domain name to different IP/server - this change may be faster and will take maximum the time used by you for the TTL value for these records.

@ bluepart

Currently (as for time of your above and this my post) latest news topic is about different thing, about not able to unsuspend suspended accounts.

No any admin posted about current "account queued" problem for now, yet. It's night in USA, their time zone, problem started ~01:26 PDT, so it's quite understandable.

@ ScatteredMusings

ALL accounts hosted on Stevie are the same at the moment.

And such situation does happend from time to time...

If you'll go to my server monitor - link in my signature - and you'll notice that "HTTP" is OK, but "server load" is not reported at all (blank, as I can not get data from my test account for the same reason) then this is most likely (but not for sure) the case. You can also check some other known websites hosted on Stevie, ie. wiki.heliohost.org (that at the moment is on this server, too) or area52.heliohost.org (admin's account).

It's displayed fine for me.

The captcha image is from google.com services (URL www.google.com/recaptcha/api/image?.... .... ...). Do you use any proxies or you have some other ideas why you can not see these images?

Since ~08:36 UTC / ~01:36 PDT (an hour and a half as for now) all accounts hosted on server Stevie are redirecting to "Account queued" page (when accessing main page) and display error 404 (when accessing any subpage). This happend from time to time...

Since ~08:36 UTC / ~01:36 PDT (an hour and a half as for now) all accounts hosted on server Stevie are redirecting to "Account queued" page (when accessing main page) and display error 404 (when accessing any subpage). This happend from time to time...